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ABSTRACT 

The Internet, the World Wide Web and the Multicast Backbone (MBone) have 
been used in a variety of ways for distance learning. Video Teleconferencing (VTC) 
classrooms have obvious value and utility but they are limited to communicate with only 
a small number of similar VTC facilities. We are most interested in open solutions which 
take advantage of the global Internet. Therefore the problem addressed by this thesis is to 
evaluate the specific benefits and drawbacks of Internet technologies in support of 
distance learning. 

This thesis includes a detailed examination of MBone, Asynchronous Transfer 
Mode (ATM) and the Distributed Interactive Simulation (DIS) protocol from the 
perspective of distance learning. An innovative design for a low-cost Web/MBone- 
capable classroom is presented. Experimental results include globally multicasting the 
IEEE Autonomous Underwater Vehicle (AUV 96) conference and digitally recording the 
1996 Monterey Bay Web Content and Access Workshop. 

One result we found is that MBone can be used successfully for distance learning 
pinposes despite common constraints of limited (128 Kbps) bandwidth. A further result 
is that an MBone classroom can be 42% as expensive as a VTC classroom if an SGI Indy 
is used and 12% as expensive as a VTC classroom if a PC is used in the classroom. 
Consequently many schools can afford Internet-based distance learning using the 
solutions presented in this thesis even though they cannot afford VTC rooms. 
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1. INTERNET-BASED DISTANCE LEARNING 


A. INTRODUCTION 

This thesis explores ways of creating distance learning environments using the 
Internet. Utilizing the Internet includes local-area, regional and global networks connected 
to the Multicast Backbone (MBone) and Asynchronous Transfer Mode (ATM) to augment 
standard Internet connectivity with high-bandwidth, low-latency links. Distance learning 
is a relatively new topic related to video conferencing. Since video conferencing has tight 
limits on the number of people who can participate and is expensive to install and 
maintain, the idea of adapting Internet-based video conferencing for distance learning is 
appealing. 

ATM is a new technology that is being investigated by many researchers. The 
major features of ATM that are important to distance learning are high bandwidth and low 
latency. These two features allow full-motion video, real-time audio, and interactive 3D 
applications at faster rates than is ordinarily possible using standard Internet links. 

Each topic mentioned above is quite broad. This thesis examines each from the 
narrow perspective of Internet-based distance learning. Related work includes establishing 
an ATM Local-Area-Network (LAN) at the Naval Postgraduate School (NPS) and 
connecting to the Monterey Bay ATM Network (Monterey BAYNET ATM). Related work 
also includes examining the testbeds in the U.S. such as Bay Area Gigabit Testbed 
NETwork (BAGNET), The International Wide-Area Year (I-WAY) project and examining 
an exemplar application, the Chesapeake Bay Virtual Ecosystem Model (CBVE). 
Furthermore a series of experiments to create an internetworked distance learning 
classroom and to support distance learning at off-site and on-site locations are performed. 
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The basic motivation for this thesis remains using the existing Internet for distance 
learning. This thesis combines knowledge and experiments together in order to provide a 
good starting point, practical examples and a reference for successors in the same area of 
research. 

B. BACKGROUND 

Studies on the MBone started in 1992. Today MBone tools are available for almost 
all platforms including PC’s. Tools for the Macs are expected to be ported soon. The first 
use of MBone at NPS was achieved in 1993 by Mike Macedonia and Don Brutzman to test 
the NPSNET real-time virtual environment simulation program over the Internet 
[Macedonia 95]. 

Tracey Emswiler used MBone tools to multicast Dr. Richard Hamming’s course 
“Futine of Science and Engineering: Learning to Learn” in real time over the global 
Internet dining an entire quarter [Emswiler 95]. This was the first full academic course 
multicast globally. MBone has often been used for multicasting special events, 
conferences and lectures. Nevertheless MBone has not been used much for distance 
learning, since the aggregate global bandwidth for MBone is limited (500 Kbps) and there 
are not many MBone connections around the world (approximately 2800 LANs). The 
number of MBone users continues to increase slowly but exponentially. Any site with 
adequate bandwidth (typically Tl, 1.5 Mbps or better) can connect. Multicast connectivity 
will continue to improve since native multicast support is built into the next-generation 
Internet Protocol (IPv6). 

Studying today’s technology encourages us to think about the future. Video, audio, 
3D graphics and other applications may work fine within the limitations of the Internet for 
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now, but the increasing demand will force the use of faster technologies. There are 
currently no “real” full-motion video, audio and 3D applications. Many competing 
demands must be considered. For example, the process of compression/decompression 
conserves bandwidth but also increases latency. Interactive 3D graphics applications may 
have lower bandwidth demands than video but higher throughput in terms of packets per 
second. Thus any experiments and any conclusions must include many considerations. 

C. MOTIVATION 

Widely distributing an application, whether or not the application is very valuable 
and useful, is mostly dependent upon economics. For the purpose of this thesis, the author 
chose to follow a method of doing things that is affordable. 

Proprietary commercial video teleconferencing is an expensive application to 
install and maintain in secondary public schools. Video conferencing requires modified 
classrooms, special equipment, and dedicated connections. However MBone classrooms 
are less of an investment since they use the Internet. Free MBone software tools are 
available for most computers. Ordinary and inexpensive video cameras and display 
monitors can usually be provided at any location. This type of equipment does not require 
trained personnel to build, maintain, or operate. Thus open Internet-based solutions are 
appealing. This thesis demonstrates working solutions for distance learning using MBone. 

Another motivation for this thesis is to give conditions and steps to multicast 
lectures with the least effort and money. Augmenting a conference or lecture haU with 
MBone capability is not prohibitively costly. Connecting classrooms now appears feasible 
and straightforward. 

Another motivation in this thesis is to explore distance learning using ATM. 
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Unfortunately significant problems with ATM precluded such a study. Our long-term 
goals include building large-scale virtual environments (LSVEs) using ATM links and the 
existing Internet, by using the Virtual Reality Modeling Language (VRML) and 
developing a virtual reality transfer protocol (vrtp) [Brutzman 96]. 

D. THESIS ORGANIZATION 

Following this introduction, the related work chapter examines previous and 
current works related to this thesis. The problem statement chapter explains the main 
problems that are taken as the reason for this research. The subsequent chapter documents 
the idea of MBone and its use at NFS. The ATM chapter summarizes ATM concepts for 
readers to let them understand how ATM relates to distance learning. The DIS chapter 
does the same thing for DIS by emphasizing use of DIS with MBone for distance learning. 
The experimental results chapter examines three major experiments performing during 
this research and evaluates their results. The experiments are building an MBoneAVeb 
classroom, multicasting the AUV 96 conference globally through the Internet by using 
MBone, and digitally recording the Monterey Bay Web content and access workshop with 
MBone software tools. The conclusions and recommendations chapter has both the results 
of the thesis and reconamendations for the future work. Following the chapters, the first 
appendix explains how to connect computers to a new network. The second appendix is a 
kind of starter kit for MBone that gives the Internet sites for downloading MBone software 
arid getting information about MBone. The subsequent appendix has abbreviations and 
definitions used in the thesis. Appendix D gives the on-line retrieval information for this 
thesis. The following two appendices document details for building and running an 
MBoneAVeb classroom, as well as planning and managing the AUV 96 conference 
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multicast. The last appendix documents the current price comparison between video 
teleconferencing (VTC) and MBone classroom. 
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11. RELATED WORK 


A. INTRODUCTION 

This chapter discusses related work within a context of what needs to be 
considered when using the Internet and MB one for distance learning. This chapter also 
includes related work on Asynchronous Transfer Mode (ATM) usage for the purpose of 
distance learning. 

There are few examples of using MBone for distance learning in the same way as 
presented in this study. Summaries in this chapter include previous and current work on 
MBone and distance learning. 

B. PREVIOUS WORK 

1. An Analysis of Internet’s MBone: A Media Choice Perspective: [Gambrino 94]- 
This master’s thesis examines the effectiveness of Internet’s Multicast Backbone (MBone) 
compressed-motion video-teleconferencing system {vat and nv circa 1994) and analyzes 
its capabilities and limitations. The analysis follows the media richness model of media 
choice and discusses seven influences on a manager’s media selection. This study focuses 
on human-factors considerations of distance learning using compressed-motion video¬ 
teleconferencing. 

2. Desktop Videoconferencing: Technology and Use for Remote Seminar Delivery: 
[Rettinger 95]- A master’s thesis that investigates the current state of desktop 
videoconferencing technology and evaluates the potential effectiveness of this technology 
for delivering interactive seminars to a remote audience. All aspects of desktop video 
conferencing are discussed in this study. A weekly seminar class was multicast using the 
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Internet MB one to demonstrate the use of desktop video conferencing for distance 
learning. 

3. Using the Multicast Backbone (MBone) for Distance Learning: [Emswiler 95]- 
A master’s thesis that documents the viability and impact of distance learning using the 
MBone. The case study documents the learning points derived from the successful world¬ 
wide multicast of the Dr. Richard Hamming course “Learning to Learn.” The research 
provided complete course coverage, world-wide, for a full academic quarter. This is the 
first documented attempt of extending traditional education methods using die MBone. 

4. Internetworking: Planning and Implementing a Wide-Area Network (WAN) for 
K-12 Schools: [Bigelow 95]- A master’s thesis documenting the design of a regional 
network, Monterey BayNet. Monterey BayNet is the network that coimects kindergarten 
through twelfth grade (K-12) students, educators and research institutions throughout 
Monterey and Santa Cruz counties on the central Cahfornia coast. This case study was the 
first step toward a networked approach for distance learning in Monterey Bay area. 

5. Bay Area Gigabit Testbed (BAGNET)- Fourteen organizations within the San 
Francisco Bay Area formed a gigabit testbed to develop and deploy the computer 
multimedia network infrastructure needed to support a diverse set of distributed 
applications in a large scale, metropolitan ATM network environment. In this project, 
ATM technology is used in large-scale teleseminars, distributed storage and on-line 
multimedia libraries in order to show the capabilities of a future Internet. The BAGNET 
home page has the information about the work in detail [BAGNET 95]. 

6. Monterey Bay ATM Network (BAYNET) - Pacific Bell awarded two years’ firee 
usage of the company’s ATM service to regional testbed consortia under the CalREN 
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(California Research and Education Network) program. The Monterey Baynet ATM 
connectivity was funded by CalREN program. Attempted applications in BAYNET 
include distance learning between UCSC (University of Cahfomia, Santa Cruz) and UC 
Extension, and also distance learning between Monterey Bay Aquarium (MBA), 
Monterey Bay Aquarium Research Institute (MBARI) using the Bay Link application 
which provides a live video link between MBA/MBARI and San Jose Tech Museum of 
Innovation (SJTMI). 

7. NFS Network Simulator (NPSNET)- The NPSNET networked virtual 
environment, developed at the Computer Science Department of the Naval Postgraduate 
School (NFS) in Monterey, California was the first distributed virtual environment 
simulation that was played over the global Internet using MBone-compatible Distributed 
Interactive Simulation (DIS) protocol [Macedonia 95]. This work is especially important 
since it demonstrates a new class of applications for the Internet. Distributed 3D real-time 
environments are also important for the future of distance learning. 

8. Remote Seminars through Multimedia Conferencing: Experiences from the 
MICE project [Sasse 94]- The aim of the MICE (Multimedia Integrated Conferencing for 
Europe) project is to enable useful internetworking between European researchers via 
multimedia conferencing technology. 

C. CURRENT WORK 

1. Multimedia European Research Conferencing Integration (MERCI) [MERCI]- 
The goal of this project is to pilot interworking between Etiropean researchers and also to 
connect to sites in the U.S. using existing facilities. This project is a successor to 
Multimedia Integrated Conferencing for European Researchers (MICE) (which ended in 
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September 1995) with additional emphasis on the integration of individual software tools 
and their porting to diverse platforms and networks. The MERCI system currently allows 
multimedia conferencing (audio, video, and shared workspace) between conference rooms 
and workstation-based facilities, hardware and software codecs, packet-switched networks 
and ISDN, using both unicast and multicast technology. 

2. Internetworking: NFS ATM LAN: [Courtney 96]- A master’s thesis that 
documents the installation of ATM technology at NFS. The objective of this case study is 
to create, test, and build an ATM network to support real-time tele-education and digital 
interactive multimedia. This case study was intended to be one foundation for this thesis, 
experimenting with ATM capabilities, and building an ATM backbone for future use in 
distance learning and other high bandwidth low-latency, multicast applications. However, 
the research concluded that ATM is currently a failure, due to the following reasons: 

• There is an interoperability problem among the ATM switches. 

• ATM is currently incompatible with IP multicast. 

• Long-haul setup is a time consuming process and the fees for the links are 
prohibitively expensive. 

• People that really understands ATM networks are few. Therefore there is a 
human engineering problem. 

» There is a crossover problem. When one connection is broken then there is no 
alternative connection to carry on the link. 


3. Internetworking: Implementation of Multicast and MBone Over Frame Relay 
Network: [Erdogan 96]- A master’s thesis that documents the implementation of MBone 
over Monterey BayNet for educational purposes. It documents the requirements for re¬ 
configuration of Monterey BayNet sites to join MBone. It shows that MBone over Frame 
Relay networks is possible and the current MBone technology provides excellent 
performance even on low-speed network connections. This thesis is especially helpful to 
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show how to configure and use MBone in networks which may possibly be used by the 
schools for distance learning purposes. 

4. The Chesapeake Bay 'Virtual Ecosystem (CBVE) Model- This model 
incorporates linked submodels of various organic and inorganic substances with various 
oceanographic processes aU of which will be spatially and temporally linked via three- 
dimensional Chesapeake Bay circulation model [Wheless 96]. Future goals include 
integrating this project completely with the Web, and showing the functionality of using 
the Internet to import or export any type of media, including the generation of 3D graphics 
object models compatible with the "Virtual Reality Modeling Language CVRML) [Carey 
96]. 

5. Internetworking: Economical Storage and Retrieval of Digital Audio and Video 
for Distance Learning: [Tiddy 96]- A master’s thesis that documents the testing and 
comparison of currently available methods of digital audio and video storage and the use 
of current transfer modes and protocols for on-demand retrieval over the Internet. This 
case study is relevant to this thesis by demonstrating digital storage of distance learning 
recordings for later retrieval over the Internet. 

D. SUMMARY 

In this chapter, related work concerning MBone and ATM in distance learning are 
summarized. One section consists of previous work and the other consists of current work. 
Studies that involve distance learning were not found, presumably due to the newness of 
ATM technology. 
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ni. PROBLEM STATEMENT 


A. INTRODUCTION 

This chapter defines and explains the problems of the thesis. Methodology, 
expected solutions to the problems encountered and success criteria are also described. 

B. PROBLEM AND METHODOLOGY 

The Internet, the World Wide Web and the Multicast Backbone (MBone) have 
been used in a variety of ways for distance learning. However, it is not clear how 
practical they are as an affordable alternative to proprietary commercial video- 
conferencing systems. Video Teleconferencing (VTC) classrooms have obvious value 
and utility, but they are limited to communication with only a small number of similar 
VTC facilities. This study is interested in open solutions which take advantage of the 
global Internet. Therefore, the problem addressed by this thesis is to determine various 
benefits and drawbacks of Internet technologies in support of distance learning. 

Specific goals include use of the Internet and the MBone for distance learning 
purposes, and to demonstrate the feasibility of a Web/MBone classroom by building it. 
Additionally, the classroom needs to be affordable so that schools which do not have large 
budgets may participate in global distance learning. The ultimate Web/MBone classroom 
must be both simple and affordable. By simple, we mean that it can be built, used and 
maintained by anybody (students or instmctors) with no special training on the system. 
The classrooms should make use of all facilities of the Internet such as Web pages, global 
multicast of audio/video. 

MBone tools have been used experimentally on several occasions throughout the 
world in the last few years. Our plan was to experiment with MBone in a systematic way 
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by increasing capacity within a changing environment. Success is defined as building and 
running an affordable Web/MBone classroom, experimenting with MBone for larger 
functions like workshops or conferences, and evaluating the results of these experiments 
for future researchers. The major point of this evaluation is to be able to recommend to 
other educational organizations how to use MBone for distance learning. We provide a 
reference for building, running and maintaining Web/MBone classrooms to assist others in 
participating in global distance learning. We also examine the suitability of Asynchronous 
Transfer Mode (ATM) networking for high-bandwidth distance learning, and the 
Distributed Interactive Simulation (DIS) protocol for large-scale virtual environments 
(LSVEs). 

The first step in reaching these goals is to build a Web/MBone classroom using 
inexpensive, available equipment. In this case, the equipment was borrowed firom different 
departments in the school. Evaluation of these results shows that MBone can be used for 
distance learning comfortably and effectively. 

After evaluation of classroom environment, the Web/MBone classroom equipment 
is used and evaluated in other environments to learn about other Internet-based distance 
learning opportunities. Subsequent steps in this evaluation include multicasting a large 
conference globally, and multicasting a small workshop from an auditorium to test digital 
recording. Digital recording is another important issue for the storage of Internet distance 
learning. The auditorium experiment gave practical experience on storing MBone sessions 
digitally and moving them through Internet when necessary. 
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C. SUMMARY 


The problem examined in this thesis is to evaluate the specific benefits and 
drawbacks of Internet technologies in support of distance learning. Open solutions which 
take advantage of the global Internet are the main interest. Goals are to include use of the 
Internet and the MBone for distance learning and to demonstrate the feasibility of a Web/ 
MBone classroom as well as the low cost. Success is having a working, affordable Web/ 
MBone classroom and showing the usage of MBone for distance learning purposes. 
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IV.MBONEATNPS 


A. INTRODUCTION 

This chapter documents recent Multicast Backbone (MBone)-related work at NFS. 
The first section gives background information on the experiments at NFS. The second 
section presents the ideas behind the design of a MBone/Web classroom, as well as the 
pros and cons of using MBone in a distance learning classroom, a lecture hall, and a 
conference. The requirements for each kind of event are presented in detail, including 
directions on how to connect to MBone. The concluding section presents some ideas on 
achieving distance learning at NFS or in any other organization. 

B. BACKGROUND 

The MBone was named by Steve Casner and has been around since early 1992 
[Casner 92]. The MBone is a virtual network that is layered on top of portions of the 
physical Internet to support routing of IF multicast packets. Because multicast 
connectivity has not yet been integrated into some production routers unicast tunnels are 
sometimes used to pass multicast. Most vendors have provided native IF multicast into 
their recent routers. 

Multicast (unlike unicast or broadcast) supports selectable one-to-many and 
many-to-many connections over the Internet. Class D Internet addresses (which have a 
first-byte value between 224 and 239) are reserved for IF multicasting. 

On the Internet, there are link layer technologies that naturally support multicast 
(such as Ethernet and FDDI). These subnets are linked by virtual point-to-point links 
called “tunnels” since some regular IF routers do not support multicast. At the endpoints 
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of a tunnel, there are multicast routers (mrouters) that encapsulate the multicast packets 
within an IP header and then send them through the tunnel. The receiving side is also an 
mrouter. It removes the IP header and deliver the packet to its group address. Mrouters are 
usually workstation-class machines having operating system support for IP multicast and 
running the public-domain “mrouted” multicast routing daemon. 

NPS has been working with the MBone for several years. Dr. Richard Hamming’s 
“The Art of Science and Engineering: Learning to Learn” course was multicast using the 
Internet by using MBone tools called Network Video (nv) for video and Visual Audio Tool 
(vat) for audio in Spring 1995 [Emswiler 95]. This experiment proved that the MBone is a 
viable asset for distance learning. 

Studies so far have merely shown that the MBone can be feasibly used for 
video/audio transmission in a multicast environment. This thesis examines ways that 
distance learning might use MBone easily and effectively on a regular basis. 

In recent years there has been a large emphasis (and expenditure of funds) on 
Video Tele Conferencing (VTC). Significant drawbacks exist with this approach 
(Figure 4.1). 

• VTC is expensive (special purpose equipment, connections, etc.) 

• VTC equipment is not completely standardized yet 

• VTC needs specially trained personnel to operate and maintain it 

• VTC is capable of few simultaneous connections (maximum 7 to 10) 

Figure 4.1. Some drawbacks of VTC. 

In comparison, using the existing Internet and MBone anywhere in the world costs 
almost nothing, is easy to install, is easy to use and maintain, and has the capability of 
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connecting numerous sites simultaneously. These are important reasons for choosing 
MBone instead of VTC for distance learning purposes. We therefore look at these issues in 
detail. 

C. MBONE/WEB CLASSROOM DESIGN 

The Internet is an undeniably good reference source. On the Internet, the World 
Wide Web (Web or WWW) allows for new dimensions in communication and vision. Any 
individual or institution can have a home page on the Internet That has increased the 
usage of the Internet for reference. Search engines made information easy to find. Static 
slides can be replaced with projections of the relevant home page screens in lectures and 
conferences. Addition of the MBone allows users to include interactive audio and video 
during a lecture or a conference. Therefore the idea of combining web browsing and the 
MBone in a lecture is a good idea for distance learning experiment. The lecture can be 
transmitted to several sites through MBone, and participants at either the near or far end 
can follow the instructor with MBone tools and Web browsers (Figure 4.2). 

These ideas are the main motivation for a MBoneAVeb classroom. Potential 
benefits are summarized in Figure 4.3 and potential drawbacks are in Figure 4.4. 

D. LECTURE HALL CONFIGURATION 

Lecture halls are different than ordinary classrooms. First of all, a lecture haU may 
accommodate 100 people or more, whereas a classroom may be made up of only 25-30 
people. This difference makes lecture hall configuration more difficult, because audio and 
video quality are more important for larger spaces. These factors must be taken into 
account when a lecture hall is configured for an MBone session such as a conference. 
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Microphones and camera(s) must be placed in the hall very carefully. 



WEB 

SITES 

ON 



Near End participants 

are listening to the instructor 

and following Web from the screen 


S peaker/Instructor 
giving a class 


Jt 

Ide/^ai 


Video Camera 
Recording for MBone 
Transmission 




Workstation running 
mbone tools 


NEAR END SIDE 


A participant ( 
• can follow both/ 
I the instructor A 
I and Web at I 
the same time \ 

' in his/her ^ 
I computer 



pants ai 
Is are ft 
[h MBone 
eb throug] 


I 





Internet 



Far-end students are 
watching MBone session 
from a monitor in their 
classroom 


Lecture Hall audiences are 
watching MBone 
on a projection screen 






A computer 
presenter 

FAR END SIDE 



20 
















* Building an MBoneAVeb class is much cheaper than building a video 
conference room. More specifically, the equipment used in MBone is ordinary 
equipment and consequently easier to find and purchase (or borrow), and you 
do not need to pay extra money for the connection as in case of video 
conferencing. 

• It is easy to use the room and it does not have to adhere to a strict schedule. 

• Since the system accepts any kind of computers and any kind of connections, 
it is easier to distribute through out any school. 

♦ A lecture or a conference can be sent and received by all MBone-capable 
networks around the world simultaneously. 

Figure 4.3. Benefits of Web/MBone classrooms for the schools. 

• Video conferencing rooms are usually separate and secured rooms, but 
MBoneAVeb classrooms are ordinary rooms so that they are not necessarily 
secured. As a result, equipment used in the classroom needs to be secured. 

• Since everybody can use the rooms for his/her own purposes, it is a little bit 
difficult to maintain the rooms, and follow the activities of people using the 
rooms. It is not necessarily a requirement to use MBone or Web for 
scheduling a class in that particular room. 

• Since the equipment used may be borrowed from a system administrator 
from another department, equipment can go back and forth for reasons not 
related to MBone. 

Figure 4.4. Some Disadvantages of Web/MBone Classrooms. 

Another factor is that the quality of the audio equipment used in lecture halls may 
need to be higher than that used in classrooms, because the noise in the lecture haU created 
by a larger number people must not be multicast. The best thing that can be done is to use 
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built-in house audio (public address system), if available for this purpose, and connect it to 
the computer system. 

Since lecture halls are usually open for public use in schools, assigning dedicated 
computer, audio and video systems to the halls is almost impossible. The problem with 
computers that are not permanently assigned is that they may need to be reconfigured each 
time they are moved to the lecture hall. Configuration of host numbers and network 
services is usually a painful operation for system administrators. 

MBoneAVeb lecture haUs can save money just like classrooms. Instead of paying a 
nearby hotel for holding a conference or a lecture, using their own assets at the school with 
zero cost is attractive to many administrators. The security of equipment issue is also 
present in lecture halls. It is difficult to secure a lecture hall that sees regular public use. 

E. REMOTE CONFERENCE MULTICAST SUPPORT 

One important event in which the MBone was used was Autonomous Underwater 
Vehicle (AUV) 96 Conference held by NFS at the Hyatt Regency Hotel in Monterey 
between 2-6 June 1996. The three-day conference was multicast globally. According to 
remote and local attendees, the conference was a worthwhile achievement with individuals 
watching the conference on their computers in different places around the world. On the 
first day the video and audio quality was occasionally poor, but after students became 
more experienced with the MBone tools and video cameras quality improved day-by-day. 

Since there was no convenient room for that size conference in the school, all the 
MB one-related equipment had to be taken to the conference location. The biggest problem 
was a lack of network connections in the hotel. Thus a network had to be constructed. 
From previous experiments, we had known that the easiest way to provide a network 
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connection was to use an Airlan bridge. This equipment is a wireless bridge connected to a 
MBone-capable subnet at the school. One connection is a main unit with an antenna at the 
school, and another wireless bridge at the hotel with its antenna directed back to the 
school acts as a repeater between the hotel and the school. Details about the topology and 
configuration may be found in Chapter VII. 

Before taking the assigned computers to the conference, they need to be configured 
for the subnet that they will be assigned. MBone tools and other programs need to be 
installed locally since the normal network file system (NFS) wiU not be available. 
Configuring computers for a different subnet is explained in detail in Appendix A. 

After moving the necessary gear to the conference hall, every item must be tested 
as if the conference has begun. Even though the equipment initially seems to be working, 
a system administrator must be present to help with inevitable problems. Most of the time 
problems are related to the system configuration, and only a system administrator with 
root permissions can fix those sort of problems. 

R MODIFYING MBONE TOPOLOGIES 

Connecting to MBone or connecting to an MBone capable networks has been 
mentioned several times. In this section, connecting to MBone will be explained. Before 
explaining the necessary steps to join the MBone, it is probably better to define a few 
terms that will be used in the reminder of the chapter. 

Tunnel: A tunnel is a point-to-point connection between two multicast capable 
routers. Since the Internet uses P unicast transmission mode, routers have to send their 
packets in IP unicast. They can not recognize the multicast D-t5q)e IP addresses. So the 
multicast router that wants to send a multicast packet across an P network wiU use this 
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point-to-point tunnel connection prepend another IP header, and set the destination 
address in the new header to be the unicast address of the multicast router at the other end 
of the tunnel. 

mrouterlmrouted: End points of a tunnel are called multicast routers (mrouters). 
They are in charge of distributing and replicating the multicast data streams to their 
destinations [Kumar 96]. They are usually regular workstations that run a multicast route 
daemon, (mrouted) to behave as an mrouter. Recently most new IP router products have 
begun to support multicasting. 

MOSPF, DVMRP: The Multicast Extensions to Open Shortest Path First (MOSPF) 
is defined in RFC-1584. Distance Vector Multicast Routing Protocol (DVMRP) is defined 
in RFC-1075. They are two different kinds of multicast routing protocols that are used by 
mrouters to build effective routing trees to transmit multicast packets to their targets. 

The procedure to join the MB one follows [Macedonia 95]. First, your network 
provider must be on the MB one. Otherwise you should create a tunnel to a network 
provider near you. This is not recommended since it may overload links with duplicate 
tunnels to separate end nodes. If you are a network provider, send e-mail to the request 
address of the mailing list for your country to be added to that list for the purposes of 
coordinating, setup of tunnels, etc. The list of e-mail addresses is in Appendix B. 

Second, you should assign a Unix workstation to be the mrouter. Download 
mrouted from one of the sites listed in Appendix B in the Internet and install it on the 
mrouter. Change the /etc/mrouted.conf file according to your requirements. This is usually 
done to create a tuimel between you and a site on the MBone. Build a kernel with IP 
multicast extension added in your workstation (if it is not already built-in) and then install 
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the kernel. 


Lastly, send an e-mail to your Internet service provider or the MBone list in your 
region asking to hook in. In this e-mail you will include “Request for tunnel” as the 
subject, and then write your endpoint configuration information. After you receive 
confirmation, you may need to make small changes in your /etc/mrouted.conf file to 
include the MBone provider’s tunnel information. After that, start the mrouted daemon 
[Kumar 96]. You test your MBone tunnel by running the MBone tools, such as sdr and sd. 
More information about each step can be found at the addresses in Appendix B. 

G. REGARDING MBONE AND DISTANCE LEARNING 

Success in using the MBone for distance learning can be achieved with a little 
funding for equipment used in MBone, and by encouraging people to experiment on 
MBone. Some of the necessary conditions to achieve MBone distance learning are shown 
in Figure 4.5. 

H. SUMMARY 

This chapter documents the use of MBone for distance learning at NFS. This 
information includes setting up an MBoneAVeb classroom, configuring a lecture hall, 
providing multicast support to a conference, and connecting to the MBone. The last 
section lists some “must do” requirements to be successful in using different aspects of 
MBone for distance learning purposes. 
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• Deploy the equipment in the MBone classroom permanently. Do not let 
other users change the configuration. 

• After setting up the classroom and reaching the goal, replace all the 
borrowed gear with permanent equipment. 

• Carefully record configuration for the classrooms and lecture halls in your 
school, in order to rebuild them if necessary. 

• Learn how to configure the computers, since it is not always possible to find 
a system administrator. 

• MBone documents, programs and routers must frequently be updated to 
gain better performance. Configurations and other information on the 
experiments are covered in Chapter VH. 

Figure 4.5. Some Necessary Conditions to Achieve MBone Distance Learning. 
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V. ATM MBONE-COMPATIBLE DISTANCE LEARNING 

A. INTRODUCTION 

This chapter examines the potential use of ATM for distance learning. In the 
“Background” section readers can find information on three generations of networking 
and communications history. The “Information about ATM” section describes moving 
data from one host to another using ATM, packaging data into cells through the ATM 
layers, and the transmission media used for ATM. In the “Internet Protocol (ff) 
Compatibility with ATM” section the author explains how unicast IP works over ATM and 
recent progress in that area of the technology. The “Integrating multicast and MBone with 
ATM” section deals with one of the primary themes of thesis, which is distance learning 
using MBone over ATM. This section also examines a major problem with ATM: inability 
to support many-to-many IP multicast. The last three sections describe arranging long- 
haul ATM connections, ATM-related work at NPS, and a report on the Bay Area Gigabit 
NETwork (BAGNET). 

It must be noted that original expectations for this chapter included experimental 
use of ATM to support distance learning. Unfortunately ATM problems encountered in 
this and a related thesis [Courtney 96] prevented accomplishing meaningful experimental 
results. Nevertheless this chapter provides a good basis for continued efforts to utilize 
ATM for MB one-compatible distance learning. 

B. BACKGROUND 

According to Sterbenz, the history of networking and communications can be 
divided into three generations [Sterbenz 95]. The first generation, which is principally 
characterized by voice communication, entertainment, and data networking, ended in the 
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1970’s. Voice communication was achieved using analog systems. Entertainment was 
broadcast of radio and television. Data communications was provided by connecting 
terminals to a host (by serial link for short distances, or by modem for long distances). 

In 1980’s second-generation networking introduced the Internet. The internal 
telephone network switches and trunks became digital for most connections. PBXs 
(Private Branch eXchange telephone switches) and mobile communications (cellular 
telephone systems) became available. In the entertainment category, cable networks, BBS 
(bulletin board systems) and on-line services (such as America On Line, CompuServe, and 
Prodigy) became utilized in daily life. In data networking, remote login and electronic 
mail were utilized while workstations and PCs were networked using Ethernet and token 
rings. For the first time connection-oriented networks using protocols like BNA, DECNET 
and SNA became available. Because the differences between protocols and network 
architectures were incompatible, most networks were poorly interconnected. 

In the third (and current) generation, the voice, entertainment and data networking 
categories are merging. Multimedia communication (data, voice, and video) runs over fast 
cell-switched and routed networks in LANs and WANs. 

Increasing demand for high bandwidth and low delay over long distances has lead 
researchers to develop several high-speed network technologies offering data rates of 
hundreds of Mbps, such as FDDI, Frame Relay, Fast Ethernet, Ether switch, and most 
recently Asynchronous Transfer Mode (ATM) [Kavak 95]. 

Among these techniques, ATM has generated the most interest due to its apparent 
flexibility and support of multimedia traffic. ATM is well suited to meet most 
requirements for high-speed networking. 
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C. INFORMATION ABOUT ATM 


The basic purpose of ATM is to prove a high-speed low-latency switching network 
to support various types of traffic such as data, voice and video. In order to achieve this 
goal ATM segments and multiplexes user traffic into 53 byte-segments called “cells” 
(Figure 5.1) [Black 95]. 


■53 BYTES 


HDR 


DATA 


5 BYTES- 


48 BYTES' 


Figure 5.1 53-byte ATM Cell 


The first five bytes are called the “cell header” and are used by User-to-Network 
Interfaces (UNIs), Network-to-Network Interfaces (NNIs) and switches to route the ceU. 
The data part of 48 bytes may include additional overhead bytes as well as data [Partridge 
95]. 

There are two distinct forms in UNI, described in [The ATM Forum 95]. Public 
UNI interconnects an ATM user with an ATM switch in a public service provider’s 
network. Private UNI interconnects an ATM user with an ATM switch in the same 
corporate network. Both UNIs share the ATM layer specification but they may use 
different physical media. Public UNI facilities used in connections between users and 
switches must be capable of spanning long distances, whereas in private UNI the 
switching equipment is located a limited distance from the user device. A possible ATM 
topology using both public and private UNI is shown in Figure 5.2. The UNI cell header 
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format is shown in Figure 5.3. 



Figure 5.2 An ATM Topology Using both Public and Private UNI. After [Black 95] 

NNI is utilized to provide smooth connections between independently operated 
ATM networks. Since the purpose of NNI is different than UNI, its cell header format is 
slightly different than UNI. In the NNI cell header format described in Figure 5.4, 12-bit 
Virtual Path Identifier (VPI) and 16-bit Virtual Circuit Identifier (VCI) are the first two 
fields. VPI and VCI together form a unique, 28-bit address for an ATM connection. As an 


















example and to explain how VPI and VCI are used, suppose that every ATM cell header is 
a telephone number that covers both VPI and VCI fields. In general, a telephone number 
has an area code and a local number, such as (408) 372-4720. In this example 408 is the 
area code and 372-4720 is the local number. When VPI is replaced with the area code and 
VCI with the local number, that combined information provides the switches with the 
connection between two end-points. First switches look at the VPI to determine if the 
number is local or not. If the number is local, the switch then looks at the VCI number and 
sends it to the destination, otherwise the switch uses the VPI to send the traffic to the next 


switch, to repeat the same procedure. 
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GFC (Generic Flow Control) 
VPI (Virtual Path Identifier) 
VCI (Virtual Circuit Identifier) 
PT (Payload Type) 

CLP (Cell Loss Priority) 

CRC (Cylic Redundance Check) 


Figure 5.3 UNI CeU Header Format. After [Partridge 95] 


Payload Type (PT) is used to distinguish between user traffic and different types of 
operations, administration and management traffic. Cell Loss Priority (CLP) is a single bit 
that indicates whether a cell will be preferentially dropped in the presence of congestion. 
Header Cyclic Redundance Check (CRC) is an error-detecting code part that is utilized for 
the five-byte ceU header. 
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Figure 5.4 NNI Cell Header Format. After [Partridge 95] 


The main difference between UNI and NNI format is Generic Flow Control (GFC) 
field in header of UNI cell. A four-bit GFC field gives UNI an opportunity to negotiate 
with the shared-access networks about how to divide cells of the different ATM 
connections into the network. GFC values are not yet defined. A value of zero is always 
used in this field [Partridge 95]. 

These definitions above are useful in understanding the terminology of a 
connection between two end points and to make a connection between two end points. 
Two new terms related to the connection are Permanent Virtual Circuit (PVC) and 
Switched Virtual Circuit (SVC). 

In PVC a connection is established according to a request firom the user, using the 
bandwidth available. Applications may use the bandwidth reserved for the connection. 
VPI and VCI numbers for that connection are permanent. 

In SVC, VPI and VCI numbers are assigned dynamically by intermediate 
switches, producing a “connection-in-request” type system. The bandwidth required is 
allocated by the switches dynamically according to the band>vidth that is available. A 
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switch receives a cell on an incoming port and reads the VPWCI values. These values are 
saved for future recognition of a specific end user. The switch also looks through a routing 
table to find a matching outgoing VPI for the incoming one. After the switch finds a 
match, it replaces the VPI number in the cell header with the new one and sends it to the 
outport for the next switch. Notice that the routing table must be built before the 
connections. This call setup process illustrates why ATM is called connection oriented. 

So far, this section of the chapter described how ATM moves data from one point 
to another. ATM sends the data by cells over a connection. At this point, a description of 
how data is packaged into the cells is relevant. This packaging process is carried out in 
ATM Adaptation Layer (AAL). Various kinds of higher-level data such as datagrams, 
voice samples, and video frames can be divided into series of cells prior to being sent over 
an ATM connection. They are subsequently restored to the original stream after final 
receipt. 

Since there are different kinds of timing requirements for data transferred through 
ATM connections, it is important to be able to support all of them. Originally the 
Consultative Committee on International Telephone and Telegraph (CCITT - now ITU) 
determined four different types of service. They were: 

1. Constant bit-rate applications (CBR). 

Send and receive data at constant bit rates (e.g. voice, video) 

2. Variable bit-rate applications (VBR). 

Send data at variable bit rates. This is a connection-oriented service that requires 
timing information (e.g. compressed video or audio) [Anujan 95]. 
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3. Connection-oriented data applications. 

Intended to support applications that use a basic network service such as X.25 
[Partridge 95]. There is no timing information requirement. 

4. Connectionless data applications. 

Intended to support datagram networking protocols like TCP/DP. 

AAL numbers have been given to each of these services listed above. AALl 

provides CBR, AAL2 provides VBR, AAL3 and AAL4 (merged into AAL 3/4) provides 

items 3 and 4 above. However it was decided that AAL 3/4 was not efficient for most data 

communications applications. Therefore a more efficient AAL5 (also called as Simple and 

Efficient Adaptation Layer- SEAL) was developed for this purpose. 

Beneath AAL there are two sublayers: Segmentation And Reassembly (S AR) 

sublayer and Convergence Sublayer (CS). SAR sublayer processes user PDUs that are 

different in size and format into ATM cells at the sending site and reassembles the cells 

into the user-formatted PDUs at the receiving site. CS multiplexes and performs loss 

detection/timing recovery, depending on the t3q)e of traffic being processed by the AAL. 

According to [Black 95] the use of these two sublayers in ATM is as follows: 

The SAR and CS entities provide standardized interfaces to the ATM layer. The 
ATM layer is then responsible for relaying and routing the traffic through the ATM 
switch. The ATM layer is connection oriented and cells are associated with 
established virtual connections. Traffic must be segmented into cells by the AAL 
before the ATM layer can process the traffic. The switch uses the VPVVCI label to 
identify the connection to which the cell is associated [Black 95]. 

The last topic in this ATM introduction is the media on which ATM cells are 

transmitted. The first thing of importance about physical media is that ATM cannot be put 

directly over a fiber optic cable or a wire [Partridge 95]. Over long distances, Synchronous 

Optical NETwork (SONET) firames are used to encapsulate ATM cells. SONET is also 
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known as Synchronous Digital Hierarchy (SDH) in the countries other than the U.S. The 
first data rate in SONET/SDH is 51.84 Mbps which is designated as Optical Carrier level 1 
(OC-1) or Synchronous Transport Signal level 1 (STS-1) (in countries other than the 
U.S.). The rate can be expressed as OC-n where n is a multiplier of OC-1 (51.84 Mbps). 
For instance when OC-12 is referred as a rate, it should be interpreted as 51.84x12 = 
622.02 Mbps. 

SONET/SDH uses frames for transmit data. Each frame consists of 90 columns 
and 9 rows. Thus one frame contains 9x90=810 bytes. For a given OC-n, n frames are 
transmitted as a single unit of transmission. So for instance, OC-1 transmits data with 
single frames where an OC-3 does the same thing with 3 frame-groups (Figure 5.5). 



SONET is not the only physical media to transmit ATM cells. Other compatible 
media include Digital Signal level 3 (DS-3) which is 44.736 Mbps, 100 Mbps FDDI 
compatible multimode fiber interface, unshielded twisted-pair (UTP-51.84 Mbps), and 
shielded twisted pair (STP-155 Mbps) [Anujan 95]. 
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D. INTERNET PROTOCOL (IP) COMPATIBILITY WITH ATM 


Interconnection of large-scale LAN and WAN networks across ATM requires a 
network layer protocol such as the Internet Protocol (IP). The operation of ATM switches, 
the primary mechanism for interconnecting current LANs and WANs across ATM 
backbones, needs to be compatible with such a protocol [Kavak 95]. 

In the so-called classical IP over ATM model, a logical IP subnetwork (LIS) 
consists of hosts and routers having the same subnetwork address and netmask [Kavak 
95], Hosts connected to the same subnet (i.e. LIS) communicate directly. However, 
communication between two hosts on different LISs is only possible through an IP router, 
regardless of whether direct ATM connectivity is possible between these two hosts. 

Even though two ATM networks may be connected to each other with native ATM 
through ATM switches, inside these networks there may be IP subnets. So the problem is 
to make IP and ATM hosts understand each other by some means. An address mapping is 
necessary between IP and ATM addresses. IP addresses are resolved to ATM addresses by 
use of an ATM Address Resolution Protocol (ATMARP) service in LIS. 

Initially, hosts are connected to the ARP server inside their LIS by using a built-in 
ATM address in the ARP server, then the ARP server uses Inverse ARP (InARP) to 
determine the IP and ATM addresses of the host. After that the hosts can submit a request 
to ARP server to get the ATM address of a given IP address. An ARP server can do this 
job only for hosts in the same subnet [Kavak 95]. 

Although the classical IP over ATM is conceptually simple and does not require 
any changes to existing systems, it is very limited, since IP routers are to be used between 
ATM subnets. In this case, any two hosts in different IP subnets that have direct ATM 


36 



connectivity between them cannot talk to each other without first visiting an IP router. 
This decreases the efficiency of the ATM performance in that network [Kavak 95]. 

In order to overcome this limitation, the Routing Over Large Clouds (ROLC) 
working group has released a new protocol known as the Next Hop Resolution Protocol 
(NHRP). NHRP is built on the classical ff model over the networks such as ATM, Frame 
Relay, or X.25. These networks are called as Non-Broadcast Multi-Access (NBMA) 
[Alles 95]. The goal is to let a host bypass some or all of the IP routers on the way by 
establishing a direct connection through the ATM fabric [Kavak 95]. 

Simply the idea in NHRP is that every NBMA LIS in classic IP over ATM has an 
NHRP Server (NHS). These servers can talk to each other and keep track of the other 
members of their subnet. When one host wants to talk to another, NHS resolves the ATM 
address of the destination if it is in the same subnet, otherwise it communicates with other 
NHSs by using IP packets. NHRP finds the destination address so that it can be given to 
the source host. NHRP also has some deficiencies. One major problem is that giving a 
direct connection between source and destination violates basic assumptions in IP routing 
[Alles 95]. This problem is particularly severe with respect to multicast. 

E. INTEGRATING MULTICAST AND MBONE WITH ATM 

The Multicast Backbone (MBone) was started in 1992. After seeing the 
capabilities of MBone multiparticipant real-time audio/video, other applications like 
conferences, DIS and distance learning were conceived. The main problem for the MBone 
is the bandwidth limitation that the Internet has today. The default global video stream 
bandwidth is 128 Kbps which is about 1-4 frames per second [Macedonia 95]. Global 
bandwidth for MBone is 500 Kbps. With better application tools such as vie, ivs, and rat. 
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with better data compression algorithms and with forward error correction, video and 
audio quality is getting better. Chapter IV and Appendix B has more information about 
MBone and MBone tools. Video conferencing, distance learning opportunities with the 
participation of many educational establishments, and the capability of large-area 
simulations (which will be described in Chapter VI) all encourage the trend to multicast 
and use MBone. ATM is a possible way to support the MBone with high-bandwidth links. 

There is no specific support in the “classical IP over ATM” protocol for multicast 
[Laubach 94], since “classical” appears to be misleading euphemism for unicast. There are 
a couple of solutions that have been proposed. Multicast Address Resolution Server 
(MARS) was introduced in [Grenville 96]. MARS is a kind of replacement of the ATM 
ARP server (ATMARP) that is introduced in [Laubach 94]. 

MARS serves a cluster, a group of hosts. All end systems in that cluster are set up 
with the ATM address of the MARS. When a node wants to participate in a multicast 
group, it generates an Internet Gateway Message Protocol (IGMP) report message so that 
all multicast routers on the subnet are informed. From then on, all multicast requests go 
through MARS if the destination node in a multicast activity belongs to another cluster. 

Possible implementation algorithms for multicast over ATM are stiU being 
explored by the Internet Engineering Task Force (IETF) working group. There is no 
standard for multicast over ATM. Even though there are a few ATM switches of different 
companies supporting proprietary versions of multicast over ATM, they are not 
compatible with each other and not compatible with multicast IP. This is big handicap for 
researchers interested in multicast and ATM. 
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E ARRANGING LONG-HAUL ATM CONNECTIONS 


ATM has been used in LANs for a couple of years. However long-distance ATM 
connections are essential if low-latency or high-bandwidth applications need to be run 
across long distances. An innovative long-distance ATM WAN was tested as part of the 
SuperComputing (SC) 95 conference. Wdeo applications at different levels of demand 
were run in a heterogenous ATM network between San Diego, California, Portland, 
Oregon and Albuquerque, New Mexico [Naegle 95]. Even though the compression rates 
of the computers did not allow using the full speed of the link (OC-3 at that experiment) 
satisfactory video quality was achieved. Other long-distance applications (such as DIS) 
are highly dependent on real-time latency in addition to bandwidth. All communications 
are limited to speed of light beside the limitation of high bandwidth. Light makes a round 
trip between west and east coasts of U.S. in about 30 ms. In order to meet human factors 
requirements explained in Chapter VI, it is necessary for any round-tiip message to not 
exceed about 100 ms to achieve interactions in a virtual environment. Thus acceptable 
latencies coast-to-coast using ATM are conceivable. In summary, the variables in long 
distance latency are ATM switching time, source/destination computer process time, and 
light transit time through fiber. ATM switch process time is getting better and better, and 
the average process time today as well as connection bandwidth is not a barrier to the real¬ 
time use, even though the ATM capable links are quite expensive and it may take several 
years to have a cross-country ATM network. The most important technical impediment to 
very low latency appears to be processing time at the end hosts. 
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G. NPS ATM LAN REPORT 


NPS has been involved in ATM since 1995. ATM is used in the NPS System 
Technology Lab (STL) and NPS Computer Center. The first goal was to establish LANs in 
these two places, then to connect them together and finally to connect to the outside world. 

In the fibrst step, two SGI Indy computers were selected to install ATM Network 
Interface Cards (NICs). In order to prevent a routing loop in the existing IP LAN, Indys 
were given a second ATM address, so that any ATM cell would not jump into IP network. 
These two machines were experimented on as peer-to-peer ATM links without any switch 
between them (Figure 5.6). This was done by setting up a PVC between the machines. 



In the second step, a Cisco A-IOO ATM switch was put between the two machines, 
to support an ATM link simulating an ATM LAN configuration (Figure 5.7). 



Figme 5.7 ATM LAN with One ATM Switch 


In the third step, a second Cisco A-100 ATM switch was added into the LAN near 
the other switch, so that the simulation of two different LANs was achieved (Figure 5.8). 
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Figure 5.8 ATM LAN Simulation by Using Two Nearby ATM Switches 


In the fourth step, STL was connected to Computer Center physically through a 
PVC connection again. Hence, instead of simulating two different LANs, the system was 
configured as two physically separated LANs (Figure 5.9). 



Figure 5.9 ATM LAN Configuration With Two ATM Switches in Separate Places 


In the last step, NPS was connected to University of California Santa Cruz (UCSC) 
through Monterey BAY NET ATM PVC connections (Figure 5.10). 

The follow-up goals are: 

• Using SVCs inside the school and between UCSC and the school 

• Using multicast and MBone over ATM inside and outside the school 

• Adding security features to ATM (i.e., Kerberos) 

• Going across the country 

Significant problems with ATM exist and can be summarized as follows: 

1. Interoperability between switches 

There is no way to guarantee communication between switches. This was seen in 
many communication problem encountered between different proprietary switches. 
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Switches have different communication features and they are not able to communicate 
with each other. 



2. Incompatibility with IP 

There is no native way to multicast with ATM. There is a lot of effort going into 
solving the IP and multicasting problems, but so far no acceptable solution has been 
found. 

3. Long-Haul Connectivity 

Myriad long-haul problems exist. These problems are especially difficult due to 
the change in the regulations concerning Regional Bell Operating Companies (RBOC)’s 
being long-haul carriers. This includes setup and tariff issues. 

4. Insufficient Trained Expertise 

The human engineering problem is currently almost insurmountable. The 
“expertise” that exists in the ATM field is minimal due to the immaturity of the 
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technology. No one at NPS had ever dealt with ATM prior to our purchasing the switches. 
All the expertise that we had was learned through trying to establish the NPS ATM LAN. 
Trying to get assistance is next to impossible due to the fact that so few people have any 
proficiency in ATM. 

5. Crossover Lacking 

If a connection is broken, there is no standby connection waiting to immediately 
take over. This scenario is heightened in the already problematic multicast situation. 

More information about the NPS ATM LAN can be found in [Couitney 96] and 
[NPS ATM LAN]. 

H. BAYNET REPORT 

According to [Garcia-Luna 95] the objectives of Monterey ATM BAYNET are: 

♦ A new educational paradigm (interactive, exploratory, current, distance 
(independent), and life-long learning opportunities for the 21st century schools, 
government, and industry of the Silicon Valley and Monterey Bay region. 

♦ Ubiquitous access and timely delivery of environmental and oceanographic 
information to users in the various economic sectors of the Silicon Valley and the 
Monterey Bay region. 

♦ Innovative information products and services that forge new linkages and 
collaborations between economic sectors and geographic regions 

♦ Dynamic dissemination mechanisms for providers of public information 
products and services. 

Two commonly used terms in BAYNET project are “teleducation” and 
“telescience”. Teleducation is equivalent to distance learning. Telescience can be 
described as remote visualization, and the control of remote experiments and interactions 
with remote scientists. 

BAYNET is an Califorma Research and Education Network (CalREN) project. 
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From the point of this thesis, the important accomplishments can be explained as follows. 

1. Distance Learning Applications 

Distance learning applications were utilized over ATM links between UCSC and 
UC Extension at the first step and between the Monterey Bay Aquarium (MBA) and 
Monterey Bay Aquarium Research Institute (MBARI) at the second step. A later goal will 
connect these links to each other and to other educational services. 

2 . Bay Link Application 

In order to show the Monterey Bay submarine canyon ecosystem to a larger world, 
MBA/MBARI and the San Jose Technology Museum of Innovation (SJTMI) were 
connected to each other by ATM networks. They used proprietary video compression 
hardware and proprietary distributed multimedia software. 

By using the Bay Link capability, students and visitors at the SJTMI can 
interactively participate in the exploration at the Monterey Canyon with MBARI 
scientists. This event is carried out in real time with full motion video from the bottom of 
the Monterey Canyon by using a remotely operated underwater vehicle and its camera. 

This application worked because the principals spent a lot of money on proprietary 
hardware, software and technical consultants. Thus it is of limited use to this project 
because it is not open and not IP-compatible. 

I. REGARDING ATM FOR MBONE-COMPATEBLE DISTANCE 
LEARNING 

ATM is promising for faster, more tmsted, higher-bandwidth networks. Since its 
physical layer must be supported by complex network connections, it will take some time 
to complete an ATM network around the country or around the world. It will also continue 



to have reliability problems since it violates yet another Internet design principle by 
pushing signaling complexity into the switches, rather than keeping complexity at the end 
hosts. However ATM continues to improve. There have been several experiments at long¬ 
distance ATM. The Bay Area Gigabit NETwork (BAGNET) covered the San Francisco 
Bay Area (explained in Chapter H). BAYNET covered a real-time Bay Link experiment 
(May 5,1995, it was the first demonstration of a transcontinental end-to-end ATM 
application with the participation of two high schools, one in North Carolina and one in 
Illinois [Garcia-Luna 95]). CANARIE covered an across-the-country network in Canada 
as well as the I1S1ET96 exhibition which covered several countries around the world. There 
are many other experiments in Europe, and in Japan. Unfortunately, in each case a great 
deal of work was required to set up long-haul links, and circuits were permanently torn 
down immediately after use. 

For the time being, existing IP networks can be included in the ATM networks by 
using inadequate protocols like classical IP over ATM. There are some problems in ATM 
shown in Figure 5.11. 

• Interoperability between switches 

• Incompatibility with IP, especially IP multicast 

• Long-haul connectivity 

• Insufficient trained expertise 

• Crossover lacking 

Figure 5.11 Significant Problems with ATM. 

The importance of multicast in applications such as simulation, scientific 
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visualization, distance learning, video conferencing and data sharing is weU understood. 
Efforts to improve ATM networks will not end soon. Hopefully these serious ATM flaws 
can be corrected and ATM wiU be useful for Internet-compatible multicast-based distance 
learning. 

J. SUMMARY 

ATM is a new technology designed to meet high-bandwidth and low-latency 
requirements of existing networks to support various types of traffic such as data, voice 
and video. However, significant problems with ATM exist. Interoperability problem 
between ATM switches, incompatibility with IP multicasting, long-haul connectivity 
problem, insufficient trained expertise and crossover lacking are the most important 
problems. Because of these problems, ATM is not ready for integrating with MBone and 
multicast for affordable distance learning purposes. When these serious ATM flaws are 
corrected, ATM may be useful for Internet-compatible multicast-based distance learning. 
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VI. DISTRIBUTED INTERACTIVE SIMULATION (DIS) PROTOCOL 

AND MBONE 


A. INTRODUCTION 

This chapter explains the DIS protocol and its use. Section B gives background 
information on DIS. Section C introduces the features of DIS, problems and solutions to 
some of these problems. Section D explains the use of DIS with MBone, limitations and 
future work. 

B. BACKGROUND 

Military warfare modeling goes back centuries. It was developed and became more 
structured in the 19th and early 20th century. The Japanese used gaming before the attack 
on Pearl Harbor, and the U.S. Navy War College wargamed possible Pacific operations 
before World War n. In the 1970’s simulations became more sophisticated by allowing for 
separate interactions between classes of weapons but there was stiU no human intervention 
in the system [Davis 95]. 

In the early 1980’s, microprocessor technology began to produce less expensive 
computers and affordable local and wide-area networks became available to connect 
computers. Eventually with these new technologies a new era in simulators started. It 
became feasible to consider developing large networks of simulators that might be 
connected for operation in real time. In 1983, ARPA developed the SIMulator 
NETworking (SIMNET) Project. The first conceptual demonstration was conducted in late 
1984, and the first demonstration involving real-time, out-the-window graphics was 
conducted in late 1985. The first platoon-level system having image generation 
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capabilities was installed in 1986. The first helicopter simulators were installed in 1987 
[Mmer95]. 

Since SIMNET was designed for Ethernet technology and relied on broadcasting, 
it was hard to extend fi:om a LAN to large distributed networks. After the Gulf War in 
1990, the necessity for large-scale simulations with as many as 100,000 entities was 
envisioned. The inefficiency of SIMNET protocol for that number of entities made 
researchers look for a more sophisticated and feasible protocol for the simulators. By late 
1992, the initial set of Distributed Interactive Simulation (DIS) standards was agreed 
upon. In March 1993, the first standards were formally approved [MiUer 95]. Currently 
DIS can support several hundred simultaneous entities. Work continues to improve DIS 
efficiency. 

C. DIS PROTOCOL 

1. Introduction 

The DIS Vision document [DIS Steering Committee 94] describes the domain of 
interest as follows. 

The primary mission of DIS is to define an infrastructure for linking simulations 
of various types at multiple locations to create realistic, complex, virtual ‘worlds’ 
for the simulation of highly interactive activities. This infrastructure brings 
together systems built for separate proposes, technologies from various services 
and permits them to interoperate. DIS exercises are intended to support a mixture 
of virtual entities (human-in-the-loop simulators), live entities (operational 
platforms and test and evaluation systems), and constmctive entities (wargames 
and other automated simulations) [DIS Steering Committee 94]. 

DIS may be defined as a group of standards being developed by the DoD, industry 

and academia to provide a basis for interoperating many different hardware and software 

platforms [Macedonia 95]. 

The main areas for the development of standards in DIS are described below. 
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a. Protocols for Data Interchange 

Some of the points in developing are precise identification of data items, a 
common representation of data items. Protocol Data Units (PDUs) and dead-reckoning 
algorithms. 

b. Communication Architecture 

Some of the related areas are type of addressing (unicast, multicast, 
broadcast), reliability, detennining bandwidth requirements, constraints, and performance 
capabilities. 

c. Security 

Development in security consists of establishment of a security policy and 
security service performance requirements, publication of security guidance documents, 
and security accreditation guidelines. 

d. World Environment Representation 

Issues for achieving environmental representation among heterogeneous 
simulators, simulations, and range systems are identifying common sources for 
environmental data, creating standards for the representation of that data, creating 
repository databases for the collection and storage of the common data. 

e. Computer Generated Forces (CGF) 

CGFs replaced Semi-Automated Forces (SAFs), designed to simulate the 
externally visible behavior of forces without requiring large numbers of manned 
simulators and people to operate them and to provide exercise for supervisory control over 
units that may have many vehicles [Hafer 95]. 

Many aspects of the SIMNET protocol such as its general principles, terminology 
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and PDU formats have been used also in the DIS standards [Macedonia 95]. The entity 
State PDU (ESPDU) structure is shown in Figure 6.1. ESPDUs can be used for reporting 
the change in status of moving entities. All 27 different PDUs are structured like ESPDU 
with fields and records designed to transfer the different types of information required for 
a common synthetic environment. The variety of PDUs developed are used for exchanging 
different types of messages between the entities. For instance, the ESPDU provides the 
means for reporting the change in status of moving platforms. Other types of PDUs 
provides related information with their names, such as Fire, Detonation, Collision. 

2. Networking Requirements for DIS 

a. Having Real-Time Simulations 

According to various studies, human users begin to perceive delay at about 
100 ms. In DIS application, it is important to have low latency to achieve realistic 
real-time simulations. For tightly coupled units (such as aircraft formation) default values 
have been defined as 100 ms where as for aU other cases it has been defined as 300 ms 
[Pullen 95]. Up to five seconds is allowed for slower-moving or stationary entities. 
Real-time requirements in a network can be achieved by using UDP, but that brings up 
another requirement which is high reliability. Detonation and Fire PDUs are required to be 
delivered more reliably than ESPDUs. Reliability can be provided by using transmission 
control protocol (TCP) but it delays delivery of sizable blocks of data whenever a packet is 
lost, and therefore is inconsistent for real-time delivery [Pullen 95]. 
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b. Multicasting 

Multicasting is a means of data transfer from one host to the other(s) in 
addition to broadcast and unicast. In multicast, it is possible to have a capability of 
one-to-many and many-to-many data transfer for a special group of hosts participating in a 
session. In a distributed large-axea network, multicast is a desirable feature. Only one copy 
of a message is sent to the members of a multicast group, minimizing bandwidth 
requirements. 

c. Security Issues 

Since DoD DIS applications have sensitive data, a means of encryption to 
provide security in the simulation wide-area network is paramount. 

A second issue for security concerns multicast. If we want to use multicast 
in the network and have several multicast groups, then we must have key management 
for distribution to the groups. Furthermore, joining and leaving existing groups 
dynamically, participating in more than one simulation, international simulations, and 
multi-level security are considered other important management issues [Pullen 95]. 

d. Capacity of a Network 

After the Gulf War in 1990, the necessity of having a large number of 
entities in the simulation exercises became more important. If such an exercise were 
conducted for 100,000 entities (which is the goal of DoD) then we would have at least 175 
Mbps on the network [Miller 95]. That number could be as high as 375 Mbps [Macedonia 
95] and this presents serious problems, because 375 Mbps of network bandwidth to each 
computer participating in the simulation is unrealistic for an affordable system 
[Macedonia 95]. 
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3. Problems With DIS 


a. Great Amount of Bandwidth and Computation Requirements 

As mentioned above, a simulation involving 100,000 entities requires a 
bandwidth of 375 Mbps. Every entity is tracked and updated, and maintaining the update 
state is achieved by sending PDUs to all other entities by the host entities. The problem 
with this scenario is that, if the entity is moving, its position, velocity, and orientation will 
change and the PDUs which has a lot of other information in them will be broadcast to all 
other entities. This redundancy is a very bandwidth-consuming process. It is even a larger 
problem if we think about inherent network redundancy in broadcasting. This is a 
principle reason for a bottleneck in large-scale simulation environment. 

The DIS protocol transmits acceleration, velocity and position data 
whenever a remote object exceeds a dead-reckoning threshold or a 5 second time-out 
period. Dead-reckoning algorithms use first- or second-order models to predict the future 
object location. Because the algorithms are highly real-time dependent, the conversions in 
updating process are heavily computational [Singhal 95]. 

b. Security 

In large-scale distributed simulation exercises, there are certainly some 
security requirements and access authorizations for participants. They need to exchange 
some information with the other participants. However, one encr 5 q)tion technology often 
used today (known as link encryption) encrypts all of the stream passing through a 
point-to-point data link. Even though this form is widely used, it has security constraints 
on the nodes because insecure intermediate nodes cannot transfer these streams [Pullen 
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95]. The other encryption method, end-to-end packet encryption, does not encrypt the 
header of the packet. It is more flexible since it allows use of insecure intermediate nodes 
in the network [Russell 91]. However the only end-to-end encryption system approved for 
mili tary use is bound to a maximum data rate of T1 link (~1.5 Mbps) [Pullen 95]. 

c. Multiplexing/Demultiplexing of Media 

The current DIS protocol requires an application layer 
multiplexing/demultiplexing for real-time data (e.g., simulation packets, audio, and video) 
rather than the network or transport layer. It is difficult to build DIS applications that can 
efficiently use all kinds of data such as audio [Macedonia 95]. 

d. Others 

Some problems are explained in [Macedonia 95] and can be summarized as 


follows: 

• For large, heterogenous simulation networks, it is necessary to 

have an “on-demand” data distribution to achieve efficiency. There is no such 
mechanism in DIS. 

• DIS does not have any method to communicate all the abstractions needed to 
present a complete and consistent view of reality (e.g., clouds, weather, smoke) 

• Another problem is fidelity. Every simulator in DIS applications is assumed to 
be truthful. In a large-scale heterogenous simulation, the quality of realism that 
each simulator has affects the realism of the exercise (e.g. a highly realistic 
simulator cannot compete against a less accurate one). 

4. Possible Solutions to Problems 

There are a variety of ways to deal with bandwidth requirements and heavy 
computation. Multicasting is the first one. Multicast minimizes network bandwidth. The 
network is not used unnecessarily by sending packets to every entity even when unneeded. 
Another advantage of multicast is that it reduces the computation at the entities. Entities 
take only the information (PDU) they need because multicast can be subscribed or 
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discriminated against in the network interface card hardware rather than the application 
layer software. Thus they do not need to perform extra computations to ignore 
unsubscribed PDUs. 

According to [Morrison 95] there are two approaches to deal with the complexity 
of the DIS protocol. One is the “Newtonian Pkotocol” by the Defense Advanced Research 
Project Agency (DARPA). The main idea is to combine the many special-purpose DIS 
PDUs (like the collision and detonation) into lesser numbers of PDUs. 

ATM is a promising approach for low-latency, high-speed network connectivity 
required by large-scale wide-area distributed simulations. We have discussed ATM in 
Chapter V. Multicast IP over ATM is still a research area. There are some implementations 
of multicast IP over ATM, but for now, they lack the capability for working with different 
brands of ATM switches. 

Instead of using the dead-reckoning algorithm that is used by DIS now, an 
algorithm like Position History-Based protocol described in [Singhal 95] may be more 
efficient. Some of the advantages mentioned in the reference can be summarized as 
follows: 

• It tracks remote objects more smoothly. 

• At wider thresholds, it smooths the motion, while DIS protocol exaggerates it. 

• By using timestamps to synchronize the remote tracking at receiving hosts, it is 
effective in addressing latency and jitter issues in real-time visualization systems. 

• It transmits a total of 386 bits, where as DIS protocol transmits a total of 672 
bits. The history-based protocol can transmit 1.75 times as often as DIS and still 
reduce bandwidth. 

• The lighter packet load is important for supporting large virtual environments 
containing large number of participants. 

• There is no additional computational overhead on sending or receiving hosts, 
and the algorithm can actually reduce computational load. 

For key management, end-to-end encryption and bandwidth limitation, there is a 
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project mentioned in [Pullen 95]. As indicated above, the only end-to-end encryption 
system currently approved for military use is good only to a maximum data rate of T1 
level. When National Security Agency (NSA) fields a new end-to-end encryptor called 
“FASTLANE” which will support ATM, it is expected to provide the data rates required 
by DIS. This encryptor standard also has some advanced features such as “key agile,” the 
ability to apply multiple encryption keys dynamically, and will achieve some key 
management goals. Multicast on ATM by using FASTLANE is a future research area. 

D. DIS AND MBONE 

As shown in Chapter VI, the MBone enables the distribution of IP multicast over 
the Internet. Since researchers have been looking for opportunities to provide multicast 
capability to DIS applications, the MBone is an excellent candidate for long-haul 
connectivity. 

NPSNET was the fixst DIS application to use IP multicast and also to be tested 
experimentally over the MBone. The NPSNET-IV networked virtual environment was 
developed at the Computer Science Department of the Naval Postgraduate School (NPS) 
in Monterey California. By having IP multicast capability, sites that participate in 
distributed simulations can be connected directly via MBone. 

After SIGGRAPH 93, the multicast version of NPSNET-IV was completed. The 
first communication was established between SRI in Menlo Park and NPS. That event 
presented an important challenge for interactive simulation. Despite a hostile network 
environment, NPSNET-IV had a small amount of perceptual latency. A more detailed 
explanation can be found in [Macedonia 95]. 

These MBone experiments were important because they showed the use of 
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multicast in DIS applications. However, the number of the participants were far from the 
DoD goal. T1 lines were used to connect sites, so the bandwidth was limited. There was a 
perceptual latency which can make the simulation performance far from real-time 
requirements. Dead-reckoning algorithms usually can reduce this perceptual latency to 
acceptable level. 

Researchers continue looking for better methods for instrumenting 3D simulations. 
Some new ideas are explained in [Brutzman 96]. We believe it is physically achievable to 
have Large-Scale Virtual Environments (LSVEs) across the country without simulator 
sickness for fully represented and fully immersed humans. There are two fundamental 
steps needed to permit the transition to building useful LSVEs: the Cyberspace Backbone 
(CBone) and Virtual Reality Transfer Protocol (vrtp). 

The network proposed for the CBone is a combination of the National Transparent 
Optical Network (NTON) and other extensions [Brutzman 96]. By having a predictable 
high-speed network with guaranteed services, we can reduce the transmission delays 
across the network and perform repeatable experiments to optimize cross-network 
performance. 

The second step is vrtp. According to Brutzman: 

“vrtp is to be the applications layer protocol used for communicating state 

information among the various participants in internetworked LSVEs” 

[Brutzman 95]. 

We intend to use the Virtual Reality Markup Language (VRML), a standard 
language for describing interactive 3-D objects and worlds delivered across the Internet 
[Carey 96]. For the high-bandwidth and low latency requirements of virtual environments, 
many of the client-server design assumptions of the Hypertext Transfer Protocol (http) are 
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no longer valid, vrtp is needed to take advantage of available transport layer functionality. 
vrQ) will add the latency-tolerant real-time behaviors functionality (e.g., audio/video 
streaming and DlS-hke behaviors) to client-server capabilities. Details about CBone and 
vrQ) can be found in [Brutzman 96]. 

E. SUMMARY 

This chapter describes the DIS protocol, problems with DIS, and some possible 
solutions for those problems. DIS is an important demonstration of the possible ways of 
using virtual environment in networks. DIS concepts make possible the use of the 
Internet-based distributed simulations for purposes such as distance learning. The 
algorithms are getting better, the connections are getting faster and larger. 3D graphics are 
becoming more accessible by using VRML. Ongoing research into protocols such as vrtp, 
3D graphics and distributed simulations hold further promise for Internet-based distance 
learning. 
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Vn. EXPERIMENTAL RESULTS 


A. INTRODUCTION 

Requirements, necessities and motivations on using MBone for distance learning 
are in Chapter IV. This chapter covers experiments carried out at NFS in which the author 
participated. Section B is about the MBone/Web classroom, explaining the issues that 
must be taken care of in the planning and implementation phases of the classroom 
experiments. Section C covers the AUV 96 Conference held by NFS between 2-6 June 
1996 and shows the difference between a conference hall configuration and an MBone 
classroom, and gives important steps to manage an MBone session in a conference hall. 
Section D covers the same topics for the Web Content and Access workshop that was held 
on 23 and 26 August 1996 in the Mechanical Engineering Auditorium at NFS. 

B. MBONE CLASSROOM 

1. Goals 

The goals of building an MBone/Web classroom can be listed as follows: 

♦ Using multicast transmission method over the existing Internet, so that a large 
number of people and schools can use it with no extra cost. 

♦ Froviding a valuable reference source. World Wide Web (Web), for the 
instructors and end users. 

♦ Froviding a distance learning opportunity for overseas military shore based 
stations for the unclassified classes. It may be used even in naval ships, after 
satellite communication came down to the real world with a convenient price/ 
performance ratio. 

♦ While addressing the issues above, keeping the cost at minimum, at least at an 
affordable level for all schools. 

♦ Motivating follow-up researchers, and providing a reference for schools that 
wants to use this kind of a classroom. 


59 



2. Hardware 


It is helpful to plan hardware requirements by asking questions about the use of the 
chosen classroom. Answers to these questions help produce requirements for the 
classroom. For the MBoneAVeb classroom at NFS, questions and answers are as follows: 
• How big is the classroom? 

The classroom is a medium-sized classroom, originally configured as shown in 
Figure 7.1. 



• What kind of equipment is there in the classroom? 

As in most classrooms, the MBone/Web classroom in NFS had one overhead 
projector and one projection screen. 
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• What are the network and power connections in the classroom? 

The classroom had one Ethernet connection to the 131.120.63.X subnet which 
already is on the MBone. In almost all classrooms there are enough power outlets for some 
equipment. Since more electrical equipment than regular classrooms is used for distance 
learning, two power strips are necessary to provide power inside the classroom 
(Figure 7.2). 
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Figure 7.2 Power and Network Conditions of the Classroom 


• What are the light conditions in the classroom? 

The classroom had regular ceiling fluorescent lights (Figure 7.3), windows at the 
back side with dark colored curtains. The problem with these light conditions is that while 
the instructor is giving a lecture, the lights must be turned off to give students the 
opportunity of seeing slides or video projection. But at the same time, there must be 
enough light source so that far-end students can see the lecture classroom from the MBone 
session and near-end students can read or write what they have in front of them at the 
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desks. Thus lighting control must be improved. A new installation of directed lights on 
each wall (as shown in Figure 7.4) might provide better lighting conditions. However this 
is a major modification. Instead, rewiring the switches for the existing lights was required 
so that lights at the back and lights at the front of the classroom could be controlled 
independently (Figure 7.5). When there is a session the rear lights are turned on, hence 
there is just enough light source for both near-end and far-end students. This solution 
works well. Figure 7.6 shows the back lights in the classroom. 



Figure 7.3 Original Ceiling Lights of the Classroom-only two banks had 
separate switches 



Figure 7.4 One Idea for Extra Lights. Lights Over Trails on the Wall 
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Figure 7.5 Two Fluorescent at the Back are Controlled Separately 



Figure 7.6. The Back Lights in the Classroom are Turned on Separately 
and All Four Banks are Now Independent 

• What may an instructor or a student want in the classroom for education 
purposes? 

An instractor may want to have: 

• An overhead for slide presentations, 

• A computer connected to the Internet, 












• An overhead and a presenter to show students to reflect the computer monitor to 
the screen, 

• At least one or two projection screens for overheads for more flexibility, 

• One VCR to play video tapes, 

• One video projector to reflect the picture coming from the VCR to another 
projection screen or a light-color wall, as it was done in NFS, 

• A TV monitor to watch far-end classroom. 

This last item forces the limits of MBone classroom design, since most of the 
computers do not have a video output on them. In most cases, the instructor may have to 
use a computer monitor to follow or to answer far-end students even though it is not the 
most convenient way. Video output cards are commercially available at additional 
expense. 

A student may want to have the following items in addition to what the instructor 
may want; 

• A TV monitor as a second source for watching video tapes, the monitor also 
helps greatly as the sound system of the classroom. In the MBone classroom, 
either an audio mixer or a sound system were used, since speakers of monitor 
were enough to hear video tape sound comfortably in the whole classroom. 

• A microphone that is put on by instructor. Far-end students need to hear the 
instmctor easily, so a wireless mike attached to the instructor was used. 

• A computer to follow Web and MBone. Even though it might be useful, it would 
be highly expensive, and as far as this thesis was concerned it was out of question. 

3. Software 

Software used in the MBone/Web classroom consists of a Web browser (such as 
Netscape Navigator, NCSA Mosaic etc.) and public-domain MBone tools. 

Web browsers are more or less the same, but preferably it should have Java and 3D 
capability. Many of the sites in the Web are using Java and VRML 3D browsers so if an 
old version of browser is chosen, it may not necessarily give the anticipated picture when 
that site is opened. 

MBone tools are also upgraded frequently. New versions of video tools, (such as 
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vie, nv) audio tools, (such as rat, vat) and session directories (such as sdr, sd) all must be 
installed on the network. In a classroom connected to a subnet in the school, there is not 
much to do with a single particular computer since they are available on a network basis. 
System administrators must be warned when a new version of these tools comes up, so 
that they can upgrade whole network. 

4. Topology 

In order to meet most of the requirements mentioned above, the following 
equipment was provided either from the NFS AudioA'ideo department or from the System 
Technology Lab (STL): 

• SGI Indy workstation with a Presenter overhead projector monitor 

• A TV monitor 

• A VCR 

• A video projector 

• A projection screen 

• A video camera 

• A wireless microphone 

The workstation needs to be near the instructor for easy use. The TV monitor 
should face the students. Two overheads projectors (one for slides and one for computer 
presenter) should be close to each other so that instructor can reach them without moving 
too much. Two projection screens are needed depending on locations of overheads. The 
video camera should be in a place so that it can cover as large a picture as it can and be 
operated by a nearby person when necessary. The VCR and video projector should be 
located in a place where anybody in the classroom can watch the tape and not obscure the 
picture since the instructor can not do all of these things by his/herself. 

Taking these factors into account, the MBone/Web classroom was configured as 
shown in Figure 7.7. This configuration has been tested for six months and has worked 
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fine, meeting the goals of this thesis. A complete reference on configuration and building 
the MBone classroom can be found in Appendix E. 



Figure 7.7 Hardware Configuration of the Classroom 


The instructor can use the blackboard, use transparencies, show slides or play 
video tape, as well as showing a Web site. The students at the near end can watch the video 
tape either from the monitor or on the wall (a cheap but useful screen), while far-end 
students can watch them through MBone playing either fi-om a TV monitor, a desktop 
computer, or a projection depending on the configuration they have. 

5. Results 

The MBoneAVeb classroom is one of the first experiments in this area. The author 
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achieved a certain level of success with this experiment. Some of the classes were carried 
out between California State University Monterey Bay (CSUMB). Web was combined in 
the classes with MBone. Video recording opportunity was also used to record some of the 
lectures and presentations for later playing through the MBone. The MBone/Web 
classroom is still used by instructors since it has been perceived as useful. Practice has 
shown that use of this equipment is easy and simple, which prevents the technology from 
obscuring instruction. Further use will likely improve it more. 

C. AUV 96 CONFERENCE 

1. Goals 

Multicasting the AUV 96 Conference through the MBone was a great opportunity 
for NPS students to use MBone. After the experience gained with the MBoneAVeb 
classroom, the author used this conference as a second step in networked distance 
learning. 

Equipment from the MBone/Web classroom was moved to the conference location 
two days in advance. The computer network was reconfigured. Since this was an 
important MBone event, lots of attention was paid to planning. Personnel management 
was especially important since an instructor and an assistant student are not enough to 
carry out a session as may happen in the MBone classroom. 

Considering the secondary goals above, the ultimate goals may be explained as: 

• To be able to manage larger events, such as conferences, exhibits, seminars, 
multicast properly by using the equipment belong to the school, and school 
workers like students and system administrators. 

• To prepare a reference for the similar events for future use both by the use of 
NPS and other educational institutions. 
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2. Hardware 


In hardware planning, similar questions to those for a classroom and answers can 
be helpful in obtaining the requirements. These are: 

♦ How big is the conference room? 

Two different rooms were used in the conference. Usually the small room had 
better video and audio recording conditions. In large halls, having a satisfactory level of 
audio is much more difficult. Even though house sound system was used in the conference 
room, there were not enough microphones for the audience so their questions sometimes 
could not be heard by the far end audiences. A solution to this problem might be using a 
wireless mike and hand it to the person who asked a question. However this lengthens the 
time for questions so instead another microphone was provided to the audience. Constant 
attention to the volume of the sound system is essential. In general, audio is harder to do 
properly than video. 

♦ What are the light conditions in the conference room? 

Light conditions are usually not a problem in conferences. Light controls were 
excellent. When the speaker wants to show a video tape or slides, lights are diminished by 
an assistant so that the person behind the video camera can take the best picture possible. 

♦ What are the network and power connections in the conference room? 

Power connections are not a problem in conference rooms since they are designed 

to support many power requirements. Network connectivity, on the other hand, was the 
biggest problem in the conference. There was no built-in network connection at the hotel. 
The best solution to that problem was using two wireless (Airlan) network bridges. These 
bridges were regular 386 PC computer with radio connections on bridging software. 
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Directed antennas were connected to the bridges so that when pointed at each other, they 
can receive/transmit packets through the air. Cellular phones were used during long¬ 
distance setup to align antennas properly. 

After establishing the network connection between the conference room and the 
school, the remaining task was to drop Ethernet cable from the rooftop Ethernet bridge 
down to the conference room, and then to connect the computers to that Ethernet cable. 

• What kind of backup equipment is necessary? 

Since conferences are usually global on the MBone, backups must be provided to 
carry on multicasting in every situation. In this event, one other workstation with MBone 
tools was available which also provided network monitoring capabilities. An 
Unintermptable Power Supply (UPS) was also used to protect expensive equipment. 

• What kind of equipment can the conference center support? 

Conference centers usually can help with the electrical, audio, and lightning 

related problems. A planning session before the conference is very helpful. 

• What are the plans for recording the conference? 

It had to be decided how many cameras are needed, e.g., a single camera for slides, 
audience and speakers, or separate cameras for each of them. The final lineup has to 
answer many questions. How do you take video tapes played by speakers, e.g., direct 
connection between a VCR and the computer, or just shooting TV monitor by a video 
camera? What kind of equipment is necessary for the cameramen, e.g., a TV monitor just 
to see what they are recording, since it is usually too tiring to look through a small CRT 
screen on the video camera for hours? We tried many of these possibilities. Most worked 
and only varied in convenience. 
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3. Software 


Software requirements are not different than for any other MBone experiments. 
This time, instead of using a network to which the computers are already connected, a new 
network environment was used. So MBone tools and network monitoring tools must be 
installed locally on the computers used in the conference. 

4. Topology 

Combining the hardware and the software requirements above, and checking with 
the hotel engineers led us to build the network configuration in Figure 7.8. This 
configuration actually belongs to the main conference center. Even though there is a size 
difference between the two conference rooms, the configurations were nearly the same. 



Figure 7.8 Hardware Configuration of AUV 96 Conference Room 

The PC in this figure was used only to demonstrate PC MBone tools, to store 
digital camera pictures and prepare them for the home page about the conference, and to 
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make ftp/telnet connections. Events could be written in html concurrendy while the 
conference was going on, by using that PC and Web connection. More details about the 
preparation and the configuration phases can be found in Appendix E Computer layout in 
the conference is shown in Figure 7.9. 



Figure 7.9. Workstation, PC, TV Monitor and VCR Configuration. 

5. Results 

The AUV 96 Conference let NPS and the author gain another challenging 
experience about MB one multicast, conference management and configuration for 
MB one. Documenting this event hopefully allows successive researchers to improve 
quality by allowing them to start firom an improved knowledge level. 

This conference was an opportunity of getting better picture quality from the 
MBone, a more flexible configuration planning knowledge, and a more realistic 
requirements analysis for these kinds of events in the future. Figure 7.10 gives a general 
appearance of the speaker at the conference. Figure 7.11 shows the picture quality in 
MBone. This picture was taken by a snapshot of the MBone video tool (vie) during the 
conference. As a comparison. Figure 7.12 shows a picture taken by a digital camera during 
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Figure 7.10. A General Appearance from the Conference. 



Figure 7.11. An Example of Video Quality of MBone Tools. 

D. MONTEREY BAY WEB CONTENT AND ACCESS WORKSHOP 

1. Goals 

The primary goal for this workshop was to test a small auditorium environment for 


MBone distance learning. One reason for this experiment is to prepare a reference for the 
follow-up MBone users of this auditorium. Another reason was to experiment using 















MB one in a different environment. Unlike the conference in a hotel, we have security at 


the school auditorium. Another reason was to experiment in digital video/audio recording 
and storage [Tiddy 96]. This is one of the first times that digital recording was done 
through MB one. Recording is especially important to enable any Internet site to record 
and play sessions at any time. More detailed information about digital recording can be 
found in [Tiddy, 96]. 



Figure 7.12. Author Monitoring Conference Multicast. 

2. Hardware 

Using the same questions as we did in the previous sections to develop 
requirements: 

• How big is the auditorium? 

NFS Mechanical Engineering Auditorium has a capacity of 110 people. Even 
though the auditorium is not small, acoustics are excellent throughout. The auditorium is 
shown in Figure 7.13. 

• What are the light conditions in the conference room? 

Light conditions were good in general. Lights could be controlled both from the 
control room and from inside the auditorium. The problem with the lights was that there 
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was not enough directed lights for the speakers. So, when the lights were dimmed for 
better view of the projection, the picture of the speaker taken by the video camera was 
almost dark. In the workshop, we tried to compensate for poor lighting design by changing 
the levels of the lights. This problem needs to be corrected. 

* What are the network and power structure in the auditorium? 

There was one thin Ethernet connection in the control booth, and one in the 
auditorium on the stage. New IP numbers were obtained from the ME department system 
administrator. So, we did not have any network connection difficulty during the workshop. 
Power, on the other hand, was a problem. Even though there were enough outlets in the 
control booth, there were not many inside the auditorium. With two power strips in a 
single outlet, the powerstrip’s circuit breaker tripped and shut down a couple of times. We 
corrected this problem by changing one of the power strips to another outlet on the wall at 
the site of the auditorium. Power outlets in the middle section of the auditorium (where 
most of the equipment was used) were not rated high enough to give the power needed. 
Another problem was that there was no way to pull cable between the auditorium and the 
control booth, other than by pulling the cables under the doors which was not a proper 
way. Therefore we couldn’t put the video camera inside the auditorium. Instead, we 
located it in the control booth. In this case we had to record behind the glass window of the 
control booth. Sometimes the light reflection on the glass was recorded unintentionally. 

• What kind of backup equipment is necessary? 

An extra workstation and an Uninterruptable Power Supply (UPS) is necessary as 
backup equipment. 
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Figure 7.13. NPS Mechanical Engineering Auditorium Amphitheater 













♦ What are the plans for recording the conference? 

We used a single video camera located in the control booth. Recording from the 
booth has two problems. There was a window and we had to take picture through that 
glass window. Sometimes, the monitor screen’s reflection or light from outside the booth 
could appear on the video. The second problem is an inability to videotape audience 
participations. Camera operators had to be careful to deal with this problem. Since there 
was no house sound system in the auditorium, a major flaw in the design of the 
auditorium, we used two wireless microphones. One was attached to the speaker, and the 
other one was a hand microphone passed to audience members who wanted to ask a 
question or speak. Since two microphones on the same channel interfered each other, we 
separated microphone channels, and selected the active microphone by changing the 
channel number on the receiver unit manually. This is not the proper way of controlling 
audio, since there was some latency. Latency caused pauses in the sound multicasted 
through the MBone. A proper mixed solution is needed. 

3. Software 

MBone tools and network monitoring tools must be installed locally on the 
computers used in the auditorium. 

4. Topology 

The configuration of the auditorium for the workshop is shown in Figure 7.14. The 
VCR and the projector were located in the second row. The reason for this is that, when 
the projector was on the stage the picture on the screen was very small. 
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Figure 7.14. Configuration of the Auditorium and the Control Booth 


When the projector was in the back of the auditorium, a cabling problem occurred 
between the VCR and the projector. We could not put the VCR together with the projector 
at the back of the auditorium, since the speakers would not be able to use the VCR. 
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Improved auditorium sound design might fix this problem. 

5. Results 

Web Content and Access Workshop was another experiment for using MBone in 
distance learning. The primary point in this event was to test digital recording. The most 
important problem we encountered during the workshop was the audio problem. Since 
there was no house sound system in the auditorium (which is unusual) we had to use two 
wireless microphones. Because they interfered with each other when they were on the 
same channel, we used two different channels. As a consequence, when we switched the 
channels between the speaker mike and audience mike, there were unnecessary pauses in 
the multicast. When the speaker and the audience talked on a subject, switching the 
channels back and forth decreased the audio quality of the multicast. This is an important 
problem to be corrected. Documentation of this event will allow more professional use of 
the auditorium in the future for distance learning. 

E. SUMMARY 

This chapter covered the experiments on using MBone for distance learning 
purposes. Section B documented the MBoneAVeb classroom, explaining the issues that 
should be taken into account in the planning and implementation phases of the classroom 
experiments. Section C covered the AUV 96 Conference held by NFS between 2-6 June 
1996 describing the difference between a conference hall configuration and an MBone 
classroom, and providing important steps to manage an MBone session in a conference 
and configuration of a conference hall. Section D examined the same issues for the Web 
Content and Access workshop that was held on 23 and 26 August 1996 in Mechanical 
Engineering Auditorium at NFS. 
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VIII. CONCLUSIONS AND RECOMMENDATIONS 


A. CONCLUSIONS 

There are two results of this study. One is that MBone can be used for distance 
learning purposes successfully despite today’s limited (128 Kbps) bandwidth reserved for 
MBone. This has been demonstrated by the MBone classroom, AUV 96 conference and 
the Monterey Bay Web Content and Access Workshop. The quality of the MBone sessions 
are nearly at the same level with proprietary commercial distance learning systems. 
Certainly, there is more work needed to achieve fuU-motion video with MBone. 
Nevertheless, we can say that MBone can be used for distance learning purposes today 
and tomorrow. 

The other result is that an MBone classroom costs half as much as a Video 
Teleconferencing (VTC) room if a workstation is used, and costs one fifth as much as a 
VTC room if a PC is used. This price comparison may become even more favorable when 
considering that schools have most of the equipment needed for MBone already in their 
inventory. In such cases the cost will be even less. Hence, most schools can afford distance 
learning even though they can’t afford VTC rooms. Appendix G provides price 
comparisons. 

B. RECOMMENDATIONS FOR FUTURE WORK 

Future improvements on use of 3D graphics, high-bandwidth networks, such as 
ATM, will be beneficial to over distance learning. 3D graphics has already been included 
in World Wide Web. Real-time virtual environments using MBone will be another way of 
utilizing MBone. NPSNET shows the path for doing this. So instead of multicasting 
video/audio signal, PDUs will travel through the MBone and players will be in the same 
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virtual environment either for a simulation or for a scientific visualization. ATM may 
provide a higher-bandwidth network environment for these works. Taking these 
improvements into account, recommendations for future work may be as follows: 

• Distance learning applications of MBone/Web classrooms must be used more 
often and more classrooms must be buUt. This does not mean that it is necessary to replace 
VTC rooms with MBone classrooms, or stop investing in VTC rooms. These two types of 
classrooms have similar purposes but are not identical. Funding new MBone classrooms 
ought to be included in the future business plans at the schools. Adding MBone support to 
existing VTC classrooms may provide the best of both worlds. 

• Using MBone with virtual environments needs to be experimented with more 
seriously. This will be a strong emphasis in next generation distributed networks. There 
are many important applications in virtual environments. In particular, more research must 
be done combining virtual environments with video/audio tools and MBone. MBone must 
be used together with 3D graphics applications. 

• Multicast ATM, ATM WAN, and ATM LAN applications need further work. 
There are many problems but the promise of ATM in support of internetworking remains 
strong. 

• An interesting application of Web/MBone classrooms might be to employ 
language interpreters on multiple audio channels with multilingual versions of home 
pages. 
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APPENDIX A. CONFIGURING COMPUTERS FOR A NEW SUBNET 


When the computers change their subnets for any reason, they have to be assigned 
new IP numbers in the subnet. Once receiving the new IP number for a computer, this 
change must be done in the new subnet. It is usually done by changing /etc/hosts file, 
where all IP numbers and symbolic names are stored. 

The /etc/hosts file is the oldest and simplest way to map names to IP addresses. 
Each line starts with an IP address and continues with the various symbolic names by 
which that address is known. A major disadvantage of the /etc/hosts file is that the data it 
contains must be replicated on every machine that wants to use symbolic names. 
Therefore, various schemes that allow a single version of the hosts file to be kept in a 
control location are used in networks. 

The Domain Name System (DNS) is one of these schemes. DNS uses Berkeley 
Internet Name Domain (BIND) system. BIND is a program that is usually included in all 
new UNIX versions. This server runs a daemon called “named.” Different operating 
systems have different file names in DNS. However, generally there are two resolution 
files for hosts. One is for resolution from IP address to symbolic name and the other is 
from symbolic name to IP address. In our subnet, they were “addrs.63” for IP-to-name, 
and “hosts.stl” for name-to-IP. These and other mapping files are located under /etc/ 
domain. 

For adding new computers to a subnet, their /etc/resolv.conf file must be corrected 
according to the new domain name server. We will talk more about this file later. On the 
server side, the two address resolution files mentioned above must be corrected to include 
the IP addresses and symbolic names of the new computers. The important thing is to 
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change the serial number of these files after making a correction. The serial number is 
basically a date group for the last effective change. The subsequent process for DNS 
change is to re-activate the system by writing “kill -HUP ‘cat /etc/named.pid”’(in Sun 
system) as a command. Again these file configuration and commands are SGI specific. For 
different computer types, related manuals must be checked. 

The other system for sharing hosts files is Sun’s Network Information System 
(NIS). NTS is not only used for sharing /etc/hosts file but also used for sharing: 
/etc/passwd 
/etc/group 
/etc/networks 
/etc/services 
/etc/protocols 
/etc/aliases 
/etc/rpc 
/etc/netgroup 

In systems using NIS, different update procedures are necessary for connecting to 
a new network. Most operating systems, such as HP-UX, IRIX, SunOS, OSF/1, ESDI 
support NIS [Nemeth 95]. In this system, basically the machine asks the server machine 
for any entries in the above files. If the client machine is moved to a new network, it will 
not be able to find the NIS server, and will fail in a number of surprising ways. NIS maps 
(the result of a process of making contents of the files by the server as to be seen through 
the network) are preprocessed by the ndbm extensible hashing routines to improve the 
efficiency of lookups. Since ndbm allows only one “key” to be associated with each entry 
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a system file has to be translated into several NIS maps. For instance, /etc/passwd file is 

translated into two maps called “passwd.byname” and “passwd.byuid”. The former is used 

_ 

to look up entries by user name, and the latter to look up entries by UID (User ID) 
[Nemeth 95]. 

First thing to do with the computers that changes subnet is to correct /vax/yp/ 
ypdomain file that has NIS domain name. The new domain name must be written in that 
file. As a second step, /etc/hosts file of the NIS server must be collected to include new 
computers’ IP addresses and names. It is also necessary to tell the machine just connected 
to the network where to send packets for routing. For SGI machines, we changed /etc/ 
rc2.d/S31network file to show the default route when the computer does not know what to 
do. In the /etc/resolv.conf, we should order the systems that the host machine will look at 
to include NIS. Now we have both DNS and NIS in our “resolv.conf ’ file. For IRIX 
operating system used in SGI machine, “hostresorder” magic word is used to make an 
order of the systems that will be checked when an IP address, or other sorts of files needed 
by the client. When we write “hostresorder nis bind local” this means, first check nis, then 
bind and then local files. If we want to include /etc/passwd file into NIS password map, we 
need to put a plus “+” sign in a line under the users passwords in that file. The last step 
with NIS is to re-activate NIS by running “ypmake” command at the server. 

However, if you choose the easiest way and use your local files, then the process 
gets simpler. In this case: 

• Change your computer’s name in etc/sys_id with the new one. 

• Change /etc/resolv.conf to appear as: 

“hostresorder local bind nis 
domainserver your new Domain Server” 

• Turn off NIS by changing /etc/config/yp content to “off’. 

• Add computer’s new name and domain to /etc/hosts file. 
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• Add new gateway address to /etc/rc2.d/S3 Inetwork file by adding 
“route add net default ‘gateway address’ threshold (usually 1)” 

If the last one does not work for some reason and you cannot connect to anywhere, 

then try to write the same sentence in the command line. This may work until you reboot 

the computer. 

This is just a network connection part of a new configuration. We also need to use 
mail, telnet, ftp, printer utilities etc. in the new network. These are made by mounting 
these programs to NFS (Network File System). That system basically allow the computers 
share files in the network. I will not go in to details of NFS configuration, because this 
goes beyond the limits of this appendix. One important issue is that, you should make sure 
the /usrAocal/bin files match up. Typically you will have /usr/local/bin NFS mounted in 
the old network. When you move, aU the /usr/local/bin programs will go away. You need 
to back up the appropriate files that are installed, such as MBone tools, Web browsers etc., 
with the correct version, usually under /usr/local directory on the local disk. 
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APPENDIX B. MBONE RELATED INFORMATION 


This appendix contains useful information about important aspects of MBone, 
including mailing lists, kernel and mrouted software download sites, MBone desktop 
application sites, and MBone related information sites respectively. 

MBone mailing lists: 


The followings are the participating networks’ e-mail addresses 


AlterNet 

CERFnet 

CICNet 

CONCERT 

Cornell 

JANET 

JvNCnet 

Los Nettos 

NCAR 

NCSAnet 

NEARnet 

OARnet 

PSCnet 

PSInet 

SESQUINET 

SDSCnet 

SURAnet 

UNINETT 


ops@uunet.uu.net 

mbone@cerf.net 

mbone@cic.net 

mbone@ concert.net 

swb@nr-tech.cit.corneU.edu 

mbone-admin@noc.ulcc.ac.uk 

multicast@jvnc.net 

prue@isi.edu 

mbone@ near. ucar. edu 

mbone@cic.net 

neamet-eng@nic.near.net 

oarnet-mbone@ oar.net 

pscnet-admin@psc.edu 

mbone@nisc.psi.net 

sesqui-tech@ sesqui.net 

mbone@sdsc.edu 

mbone@sdsc.edu 

mbone-no@ uninett.no 


MBone request addresses for your region to be added to MBone mailing lists for 
purposes of coordinating setup of tunnels, etc: 


mbone-eu: 

mbone-jp: 

mbone-korea: 

mbone-ca: 

mbone-na: 

mbone-oz: 

mbone-sg: 

mbone-uk: 

mbone: 


mbone-eu-request@ sics.se 

mbone-jp-request@wide.ad.jp 

mbone-korea-request@ co smos.kaist. ac.kr 

canet-mbone-request@canet.ca 

mbone-na-request@isi.edu 

mbone-oz-request@intemode.com.au 

mbone-sg-request@lincoln.technet.sg 

mbone-uk-request@cs.ucl.ac.uk 

mbone-request@ isi.edu 


Europe 

Japan 

Korea 

Canada 

North America 

Australia 

Singapore 

UK 

other 
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These lists are primarily aimed at network providers who would be the top level of 
the MBONE organizational and topological hierarchy. The mailing list is also a hierarchy; 
mbone@isi.edu forwards to the regional lists, then those lists include expanders for 
network providers and other institutions. Mail of general interest should be sent 
mbone@isi.edu, while regional topology questions should be sent to the appropriate 
regional list. 

For all Remote Conferencing related issues, subscribe to: 
rem-conf-request@ es.net 

For all Conference Control related issues, subscribe to: 
confctrl-request@isi.edu 

For Radio multicasts on MBone, subscribe to: 
vat-radio-request@ elxr.jpl.nasa. gov 

For RSVP discussions, subscribe to: 
rsvp-request@isi.edu 

For Integrated Services issues, subscribe to: 
int-serv-request@isi.edu 


MBone kernel and mrouted software download sites: 

Version 3.8 of Mrouted and Version 3.5 of IP multicast OS kernel extensions are 
available at the following sites. 

For all platforms, http:llwww.merit.edulnet-researchlmbonelindexlplatform.html 
For SGI, ftp:llftp.sgi.com 

For Solans, ftp://ftp.uoregon.edu, andftp://playground.sun.com 
For DEC-Alpha running OSFl Vl.Q, ftp://chocolate.pa.dec.com 
For FreeBSD ftp://ftp.parcxerox.com 

For HPAJX 9.05, ftp://ftp.parcxerox.com 
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MBone desktop application software download sites: 


For all platforms 

http://www.merit.edu/net-research/mbone/indexlplatform.html 

For the Unix OS platform: 

Audio Conference Tool (VAT 4.0): 
ftp://ftp.ee.lbl.gOv/conferencing/vat/alpha-test/vat-4.0* 

Audio Conference Tool (Nevot): 
ftp://gaia.cs.umass.edu/pub/hgschulz/nevot 

Video Conference Tool (NetVideo): 
ftp://parcftpjcerox.eom/pub/net-research/nvbin-3.3* 

Video Conference Tool (IVS): 

ftp://zenon.inria.fr/ivs/rodeo/ivs/version3.3m3/ivs3 3m3-* 
Video Conference Tool (Vic 2.7): 

ftp://ftp.ee.lbl.gov/conferencing/vic/alpha-test/*-vicbin-2.7.* 

Shared WhiteBoard Tool (wb): 

ftp://ftp.ee. lbl.gov/conferencing/wb/wb-1.5 7* 

IMM (JPEG Images): 

ftp://ftp.hawaii.edu/paccom/imm-3.3/imm-* 

Shared Mosaic 
ftp://ftp.eit.com 

Session Directory Rendezvous Tool (sd): 
ftp ://ftp .ee. lbl.gov/conferencing/sd/sd-1.13* 

SDR 

ftp ://ftp .parcjcerox.com/pub/net-research/apps/sdr 

MMCC Rendezvous Software: 
ftp://ftp.isi.edu/confctrl/mmcc/. 

MBone applications for the Macintosh 

Video Conference Tool (Cu-SeeMe) (no multicast support) 
ftp://gated.cornell.edu/pub/video/Mac.CU-SeeMe* 
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Maven Audioconferencing Tool (no multicast support) 

ftp:llkl2.cnidr.orglpublMaclDir-SoundstufflMaven-*.sea.bin (MacBinary) 


MBone applications for PC/Windows 

Video Conference Tool (Cu-SeeMe) (no multicast support) 
ftp:/lgated.comell.edulpubfvideolPC.CU-SeeMe* 

Vic, Vat, Nv, and Sdr 

ftp .ilftp .ee.lbl.gov/conferencing 

Sd, Vat, Nv 

ftp:llftp.nus.sglpublzllEE/MBONE 


MBone related information sites: 

The JPS MBONE Page in England 
http://www.cl.cam.ac.ulclmbone/ 

RIPE MBone WG Page 
http:llwww.it.lith.sel~e93 jndalmbonelripewgl 

The AT&T MBONE Page 
http://www.research.att.comlmbone-faq.html 

MBone/IP Multicast Tools 
ftp://agate.lut.ac.uJc/pub/mbone/ 

Naval PostGraduate School MBone information page 
ftp://taurus.cs.nps.navy.mil/pub/mosaic/npsjnosaic.html 

Geneva University MBone page 
http://www.unige.ch/seinf/mbone.html 

NLM MBone Page 

http://www.nlm.nih.gov/reports.dir/multicasting.dir/DOCS.dir/ 
multicast_details.html 

Digital MBone Page 
http://chocolate.pa.dec.com/mbone 

SigNet Home Page 
http://www.acm.uiuc.edu/signet/ 



APPENDIX C. ABBREVUTIONS 


AAL 

ATM Adaptation Layer 

ARPA 

Advanced Research Project Agency 

ATM 

Asynchronous Transfer Mode 

ATMARP 

ATM Address Resolution Protocol 

AUV 

Autonomous Underwater Vehicle 

BAGNET 

Bay Area Gigabit Testbed NETwork 

BAYNET 

Bay Area Network 

BBS 

Bulletin Board Systems 

BIND 

Berkeley Internet Name Domain 

CalREN 

California Research and Education Network 

CANARIE 

Canadian Network for the Advancement of Research, Industry 
and Education 

CBone 

Cyberspace Backbone 

CBR 

Constant Bit Rate 

CBVE 

Chesapeake Bay Virtual Ecosystem Model 

ccm 

Consultative Committee on International Telephone and 
Telegraph-Now ITU 

CGF 

Computer Generated Forces 

CLP 

Cell Loss Priority 

CRC 

Cyclic Redundancy Control 

CS 

Convergence Sublayer 

CSUMB 

California State University Monterey Bay 

DIS 

Distributed Interactive Simulations 

DNS 

Domain Name System 

DS-n 

Digital Signal level n 

ESPDU 

Entity State PDU 

GFC 

Generic Flow Control 

HTTP 

Hypertext Transfer Protocol 

IETF 

Internet Engineering Task Force 

IGMP 

Internet Gateway Message Protocol 

IP 

Internetworking Protocol 

ITU 

International Telecommunications Union 

I-WAY 

International Wide-Area Year 

LAN 

Local-Area Network 

LIS 

Logical IP Subnetwork 

LSVE 

Large-Scale Virtual Environment 

MARS 

Multicast Address Resolution Server 

MBA 

Monterey Bay Aquarium 

MBARI 

Monterey Bay Aquarium Research Institute 

MB one 

Multicast Backbone 

MICE 

Multimedia Integrated Conferencing for European Researchers 

MOSPF 

The Multicast Extensions to Open Shortest Path First 

mrouter 

multicast router 

NBMA 

Non-Broadcast Multi-Access 
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NFS 

Network File System 

NHRP 

Next Hop Resolution Protocol 

NHS 

NHRP Server 

NIC 

Network Interface Card 

NIS 

Network Information System 

NNI 

Network-to-Network Interface 

NFS 

Naval Postgraduate School 

NPSNET 

NPS Network 

NSA 

National Security Agency 

NTON 

National Transparent Optical Network 

nv 

Network Video 

OC-n 

Optical Carrier level n 

OCRInet 

Ottawa Carleton Research Institute net 

PBX 

Private Branch eXchange 

PDU 

Protocol Data Unit 

PT 

Payload Type 

PVC 

Permanent Virtual Circuit 

ROLC 

Routing Over Large Clouds 

SAF 

Semi-Automated Forces 

SAR 

Segmentation And Reassembly 

SDH 

Synchronous Digital Hierarchy 

SEAL 

Simple and Efficient Adaptation Layer 

SIMNET 

SIMulator NETworking 

SONET 

Synchronous Optical NETwork 

STL 

System Technology Lab 

STRICOM 

Simulation Training and Instrumentation Command 

STS-n 

Synchronous Transport Signal level n 

SVC 

Switched Virtual Circuit 

UCSC 

University of California, Santa Cruz 

UID 

User ID 

UNI 

User-to-Network Interfaces 

UPS 

Uninterruptable Power Supply 

VBR 

Variable Bit Rate 

VCI 

Virtual Circuit Identifier 

VPI 

Virtual Path Identifier 

VRML 

Virtual Reality Modeling Language 

vrtp 

virtual reality transfer protocol 

VTC 

Video Tele Conferencing 

WAN 

Wide-Area Network 

WWW 

World Wide Web 
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APPENDIX D. ON-LINE AVAILABILITY OF THESIS PRODUCTS 


Postscript and html formats of this thesis are available at 
http:llwwwMlMps.ruivy.mill~iirgltamerltkesis.html. 
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APPENDIX E. BUILDING AND RUNNING MBONE/WEB 


CLASSROOM 

This appendix documents the connection configuration of an MBoneAVeb 
classroom from a more technical and detailed perspective. The first part is the 
configuration part and the second part is a user reference to run the classroom and 
necessary MBone tools. 

The ways to determine the hardware requirements and hardware, software, and 
topology are explained in Chapter IV and Chapter VII respectively. In this part, the author 
documents necessary information for those who want to get an MB one/Web classroom 
working in their school. Audio/video connections of the MBone/Web classroom are 
shown in Figure E.l. 

1. How to make connections in the classroom. 

a. Connect the wireless microphone to the video camera. 

Wireless microphones are made of two separate parts. One is the receiver 
part, and the other is the transmitter part. On the video cameras, there is usually a jack for 
external microphones. Connect one end of your wireless microphone cable into this jack. 
Plug the other end of the cable to the “audio output” jack on the receiver part of the 
wireless microphone (don’t turn on anything yet!). Plug the antenna into the “antenna” 
jack. You will see the necessary information about the other part of the wireless 
microphone set later on. 
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Figure E.l MBone Classroom Connections 


b. After putting your video camera over the tripod, you should plug the 
power adapter’s cable into the camera. 

Take the cables and connect them into the adapter’s back panel according 
to the Figure E.2. If you need connectors for different types of cable (you usually do. 
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because it changes from camera to camera) provide these connectors. Put a blank tape into 
the camera and set the “normal” or “record” position on the camera. This does not 
necessarily mean that you should start recording. There is usually a record selector on the 
cameras. This is important because otherwise you can not use the wireless microphone at 
all. 


ADAPTER’S BACK PANEL CONNECTIONS 


1 VIDEO AUDIO 1 

OUT 

OUT 

rcaO 

1 

O RCA 

1 - 

T 

TO VCR 

T 

TO VCR 


Figure E.2 Video Camera Power Adapter’s Back Panel 
c. Make the connections in the vcr’s back panel according to Figure E.3. 


VCR’S BACK PANEL CONNECTIONS 


FROM 



ADAPTER 

(CAMCORDER) 

AUDIO 

O RCA 

IN 

VIDEO 

BNcO 

IN 

TO 

PROJECTOR 

RCA 

BNC Oq^— 


FROM 

ADAPTER(CAMCORDER) 


TO^ 

PROJECTOR 


Figure E.3 VCR’s Back Panel Connections 


d. Make the connections in the projectors back panel according to 


Figure E.4. 


I have used “video in 1” part on the back panel. 
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PROJECTOR’S BACK PANEL CONNECTIONS 


FROM 

VCR 

VIDEO INI 

TO 

MOMTOR 

FROM 

VCR 

RCA RCA 

AUDIO IN AUDIO OUT 

TO 

MONITOR 





Figure E.4 Projector’s Back Panel Connections 
e. Make the connections in the TV monitor’s back panel according to 


Figure E.5. 


I have used “line A” part on the back panel. 


TV MONITOR’S BACK PANEL CONNECTIONS 



VIDEO 


FROM 

LINE A 


PROJECTOR 






TO 

f I OTPT T3TvT/~' 


INDY^ 

1 ) UUi J5JNC 


FROM 

PROJECTOR 

_ 

AUDIO 

_/^LEFT 

RCA 

RIGHT 

00 



TO 

INDY 


Figure E.5 TV Monitor’s Back Panel Connections 


/. Make the connections in Indy’s back panel according to Figure E.6. 
Indys have only video input and no video output. So this issue must be 
taken into consideration when making these kind of configurations. I assume that you have 
an installed Indy camera in the system. 
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INDY’S BACK PANEL CONNECTIONS 


FROM FROM TV FROM 


MIKE MONITOR INDY DIC 

MANY MANY | CAMERA 

ITAL 

RCA 


♦ i, 

? ,a- c 

5 C 



Figure E.6 Indy’s Back Panel Connections 


g. Now plug all the power cords of the equipment, turn them on. 

You should turn all of them on to have the system working. 

h. Turn on the receiver part of the wireless microphone. 

You should turn the volume knob to the right, and hear a “click” sound. 
Also you should check the battery lamp. To turn on the transmitter part of wireless 
microphone, you should slide the button on this part to the opposite side of “off.” You will 
need 1-2 sets of batteries per day of use. 

2. How to work with the MBone tools 

a. Login to the computer if it is not already logged in. 

b. In the unix shell window, write ‘‘sdr^’ to run the MBone application 

program. 

c. You should see a window that shows all the MBone sessions 


(Figure E.7). 

If you want to join one of them, just double click on the session, then skip 

to step g. 
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Figure E.7 Session Directory Window. 


d. If you need to create a new session, click the *^New” button. 

e. On the ‘‘Create” window (Figure E.8) you will see, 

Fill the name of the “Session Name” and the “Description” parts by writing 
a name and a short description of the session. Click “video” button and choose the video 
software by clicking and choosing one under “Format” column. Make sure that in the 
“Scope” part, “Site” is highlighted unless you are sure that you want to make a regional or 
global MBone session. When you are finished click the “Create” button to create the new 
session. 

/. Return to step c and follow the instructions. 

g. When the session is opened, you should see a “Session Information” 
window (Figure E.9). 
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Figure E.8. Create New Session Window in Sdr 


h. When you click *^StartAll” button in Figure E.9, you should see two 
different windows. 

One is video tool window (“vie” in our example), and the other is “Select a 
tool” window (Figure E.IO). Click the “vat” or “rat” button (“vat” in our example) on the 
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window. When you click “Start tool” button you will see “visual audio tool” (vat) window 
(Figure E. 11). Click the “menu” button on the window. You should click on the “full 
duplex” at the upper part of the window (Figure E.12). Then “dismiss” the window. 



Figure E.9. Session Information Window 



Figure E.IO. Select a Tool Window. 
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Figure E.ll. Visual Audio Tool (vat) Window. 


i. You can switch the microphones from “mike” button on the visual 
audio control panel (Figure E.13). 

Also you should click on the “talk” above the “mike” button to use full 
duplex mode which means you can send and hear at the same time. 

j. Click on the “menu” on the “vie” window (Figure E.14). 

k. Choose the camera you will use by clicking the “port” button at the 
middle of the window (Figure EJ5), and selecting the “digital” for Indy camera, or 
“analog” for video camera. 

l. Click on the “transmit” button at the top of the window to send your 
picture to the network. 
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Figure E.12. Vat Menu Window. 



Figure E.13. Microphone Button on Vat Window. 
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Figure E.14. Vic Window. 



Figure E.15. Vic Menu Window. 
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m. You should see near end picture on the “vie” window (Figure E.16). 
If you click on the picture, you can enlarge the picture. 



Figure E. 16. Near End Picture in Vic Window. 

3. How to operate in a built and connected classroom 

a. Turn on the computer, external harddisk, TV monitor, video camera. 
Put a blank tape in it Make sure that “rec” led is on. Otherwise push the 

“rec” button on the panel. This “rec” is not the same as “record” button which is red and 
let the camera record. Remove the cap from the lens. 

b. Turn on the receiver part of the wireless microphone. 

Turn up the volume control to the right. Make sure the red led is turned on, 
and “low bat” led is off. 

c. Turn on the transmitter part of the wireless microphone. 

Slide the “xmtr off’ button to the right and keep the other button on 
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“audio”. Make sure the red led is turned on, and “low bat” led is off. 


d. TV monitor must be showing *‘UNE A” on its front panel. 

e. Now all the equipment should be turned on, and you should see what 
the camera is recording on the tv monitor. 
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APPENDIX F. PLANNING AND MANAGING A MULTICAST 
SESSION FOR AUV 96 CONFERENCE 

This appendix documents what was done in the planning and during the AUV 96 
conference. The first part examines the preparation for the conference, determination of 
the requirements both for equipment and for people. The second part describes the 
hardware/software configuration for the conference and lessons learned. 

1. Preparation for the Conference 

It is always good to make a list first of what is needed in the conference. This list 
should include both the equipment and the people. Two weeks prior to the conference, a 
conference room walk-through must be done to become familiar with the location where 
the equipment wUl be setup. This is especially important for final configuration issues, 
since what is expected is not always the same as what people prepare or have in the 
conference room. After the walk-through and discussions with the people in charge of the 
conference rooms, a final configuration can be made. 

The last step prior to the conference is to test all the equipment that will be used in 
the conference with its final hardware/software configuration. This testing permits 
effective troubleshooting and dramatically decreases the time spent for the same purpose 
during the conference. Testing the equipment may reveal some additional missed points. 
In AUV 96, we used two Airlan wireless bridges to connect conference rooms to one of 
the subnets in NPS. Therefore it was a good idea to test the bridges before the conference 
but in the same location as they would be used in the conference. The bridges were the 
most important part of the job. If they didn’t work, nothing could be done with MBone, 
since there were no network connections in the conference room. 
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Two or three days before the conference, all the equipment was packed and made 
ready for moving to the hotel. The next day, the equipment was moved to the conference 
room, all the configurations set as planned, and tests performed. A watch bill is needed for 
people deployed in the conference. For each session, one person needs to work with the 
computer (MBone tools), one person needs to operate the video camera (since we had 
only one video camera) and one person is a substitute either for the computer operator, or 
for the video camera operator. So three people were used. It is advisable to have two 
different watches in a day period, since it is not so easy to stay there for eight horns and be 
fully alert and cautious. 

Equipment requirements for AUV 96 conference were as follows: 

♦ Two Indy workstations, with at least one presenter. Presenter is very useful if the 
speaker from your school wants to show a home page or anything using a Web browser. 

♦ One PC with MBone tools and network tools installed (win95). 

♦ One UPS (not a small one, it can support at least 6-8 plugs). 

♦ One video camera (this may change depending on the configuration you made). 

♦ Two VCRs (one is used by the speakers, file other is used by you. It is good to 
have at least one SVHS VCR, since it has more input and output jacks than regular ones). 

♦ Two TV monitors, one big screen and one small screen like 13”. The big one is 
useful either for the cameraman to see what he/she is shooting, or audiences to see the 
speaker closer, and watch the video tape that the speaker plays. The small one is necessary 
on the computer desk to see what the video is recording and what you are multicasting. 
The number of TV monitors also increases when the number of video cameras increases. 

♦ One tripod (it is one for each video camera). 
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• One video projector for the VCR that is used by speakers. 

• One prerecorded test video tape to see if the configuration related to VCR is 
working. 

• One pair of walky-talkies or cellular phones (at least), this is extremely 
important, when you are testing or working with the wireless bridges, on the roof. You 
need to talk to the people down in the conference center to verify that the network is 
working. 

• One cellular phone to get in touch with the school for the network confirmation 

again. 

• One wireless mike as a backup for house sound system and spare batteries. 

• One head phone to listen to the sound you are transmitting fi:om MBone. This is 
also important since usually, you may disturb audiences if you try to listen to the sound 
directly from the monitor. 

• A long Ethernet cable and connection tools to make your own Ethernet 
connections as you wish. 

• Three or four power strips to make use of a limited number of power outlets for 
your large numbers of equipment. 

• Blank video tapes, labels etc. 

2. Conference Period 

With the requirements above, the connection schema of the conference room is 
shown in Figure F.l. Antennas used with the wireless bridges are directed antennas, so 
they need to see each other with correct polarization (means that they need to be 
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symmetrically aligned, either vertically or horizontally), the audio is connected to the 
audio mixer provided by the conference center. The audio was taken from that audio mixer 
to the S VHS VCR. One good thing about the audio mixer was that it was close to the 
system. The operator could turn up or turn down the volume of individual microphones, if 
they interfered with each other. The good thing about the VCR used was that it had two 
input and two output audio/video jacks. This gave an important flexibility with 
connections. The microphone stand was placed in the middle of the auditorium. A large 
TV monitor was used by the cameraman to see what he was shooting since the view finder 
of the camera was too small to look through for hours. The same monitor was also used by 
the audiences who were on the far side of the room, to see the speakers, slides, or video 
tapes better. 

3. Lessons Learned from the Conference 

Some notes can be listed as follows: 

♦ Speakers should be requested to prepare their slides in a predetermined font and 
size. Some slides were really impossible to see through MBone, even when maximum 
zoom was used. Actually these slides couldn’t be read by near-end audiences either. Our 
rule of thumb for slides over the MBone is that good slides look fine and bad slides look 
worse. 

• We originally thought that, in order to multicast a good picture quality we should 
set the vie quality according to the object that is shot. For instance, if a slide is shot, then 
we might increase the quality by decreasing the amount down to 1 on the vie menu (Figure 
F.2). 
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Figure F. 1 AUV 96 Conference Configuration and Connections 


































Figure F.2 Vic Menu Wndow 


* There were several problems with the network. These were not usually hardware 
problems. Since there are many subnets and linked tunnels between these subnets, when a 
system administrator tries to install a new router, or a daemon, he/she may delete a tunnel 
or forget to re-ran the mrouter daemon. That may cause a variety of problems. Fortunately, 
we found the network administrator by phone to make the network run properly again in 
each case. As a consequence, it is a good idea to send e-mails to all system administrators 































































































































at the school informing them of session time. 

♦ Labeling all cables and equipment before tearing down when you are finished 
with the conference can save a lot of time in matching cable to machine later. 

• If battery powered equipment is used, then be sure that all the batteries are fully 
charged and there are also some spares. 
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APPENDIX G. PRICE COMPARISON OF MBONE AND VTC 


The following information provides a simple price comparison of different types 
of MBone classrooms with different types and quality of VTC classrooms. One important 
thing to point is this comparison does not include a quality comparison. Since VTC is a 
commercial system, its quality is supposed to be higher than the MBone while Web/ 
MBone classroom has greater functionality than VTC classroom due to Web connectivity. 
Our purpose is to show that the MBone is an effective and affordable system that can be 
used by any public school, not necessarily to show the highest quality or the most 
functional one. 

The NFS VTC classrooms costs $45,000 and contains the equipment listed in 
Figure G.l [Walsh, 96]. 


• 

VTC system 

FictureTel 4000. 


FC 

For word processing or presentation purposes. 

♦ 

Imux 

Necessary for bandwidth higher than 112Kbps. 

# 

TV Monitor 

Three TV monitors are used. 

• 

Fax 

Used for documentation transfer to the far end. 

♦ 

Document camera 

Used for viewing slides or PC presentation. 

♦ 

Folycam 

The main camera that is used in the VTC classroom. 

♦ 

Auxiliary camera 

The second camera that is used in the classroom. 

• 

VCR 

Two for recording and one for playing. 

• 

NTl 

Terminator for ISDN. 

♦ 

UFS 

Uninterrupted Fewer Supply. 


Auto microphones 

Microphones in the classroom. 

♦ 

Scan convertor 

Converts FC image to the digital data for ISDN. 


Figure G.l. NFS VTC Classroom Equipment List. 


Various configmations of a Web/MBone classroom are shown in Figure G.2. 
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System ID 

Price($) 

Classroom 

Classroom 

Receive-only 


(Indy) 

(PC) 

(Minimum PC) 

Video Camera 

0.5K 

X 

X 


TV monitor 

0.7K 

X 

X 


Indy (w/presenter) 

17K 

X 



Pentium (PC) 

1.5K 


X 

X 

Digital camera 

0.15K 




Video capture card 

0.2K 


X 


LCD presenter 

2K 


X 

X 

VCR 

0.2K 

X 

X 


Wireless microphone 

0.15K 

X 

X 


Overhead projector 

0.2K 

XX* 

XX* 

X 

Projection screen 

0.15K 

XX* 

XX* 

X 


TOTAL 

$19,250** 

$5,950*** $3,850 


* Two of them were used. 

** It costs $18,750 when digital camera is used instead of video camera. 
*** It costs $5,600 when digital camera is used instead of video camera. 


Figure G.2. Web/MBone Classroom Equipment and Price List. 


It should be noted that Figure G.2 disregards the cost for configuring the 
classrooms themselves for distance learning purposes, i.e. building special walls or 
installing directed lights. In our MBone classrooms we didn’t pay for these kinds of 
expenses. For a VTC classroom, it is essential to upgrade the room configuration for 
adequate audio/video quality. Internet connection charges are separate and likely identical 
in each case. 

The following numbers give the cost ratio of each system being used. 

Web/MBone classroom (SGI Indy)/VTC classroom at NPS: 42% 

Web/MBone classroom (PC receive)/VTC classroom at NPS: 8% 
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Using these ratios, we can say that a Web/MBone classroom using SGI Indy can 
be 42% as expensive as a VTC classroom at NFS, and a Web/MBone classroom using a 
PC in receive-only mode can be 8% as expensive as a VTC classroom at NPS. Even 
though there is currently no MBone video tool to transmit from a PC with a video capture 
card, by assuming there will be in the near future, ratios of a Web/MBone classroom using 
a PC in with a capture card is as follows: 

Web/MBone classroom (PC transmit)/VTC classroom at NPS: 12% 

Consequently, PC Web/MBone classrooms appear to be affordable for schools. 
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